J3/16-243 To: J3 From: Malcolm Cohen Subject: Editor's report for 16-007r2 Date: 2016 September 07 1. Introduction This is the editor's report for the production of 16-007r2. Papers from meeting 210 were applied in approximately the order of passing. Please do not revise this paper. This paper is the editor's report. It is not the response to the editor's report. 2. Papers This section lists the papers in the order I processed them, which is almost but not quite the same order the meeting passed them. 16-187r2: I did add the optional note. Done. 16-188: Sorry, this turns a perfectly good sentence that is not ambiguous into terrible style and bad grammar. Normally I would not quibble quite so much over mere wordsmithing but that is all this paper is. REJECTED. 16-189r2: I could not find line 324 on page 403, so I did it at line 34. Done. 16-192r2: [25:1-2] Also appended a semi-colon (line 3) to the end of this item. [27:16] "X%IM is negative zero" -> "X%IM is negative real zero" (consistency with line 15). COMMENT: I note that "Nature of deleted features" is no longer accurate, and has not been for some time. In particular, it claims that these features "were not included in Fortran 95"; this is not true for two features: (1) vertical format control was in F95 and deleted in F2003; (2) nonblock DO was in F2008 and only deleted this time around. COMMENT: Also, it claims that "better methods existed in Fortran 77", and this is untrue for nonblock DO (F90 introduced block DO). 4.4.1 General is also misleading on this. COMMENT: The hard-coded numbers of deleted items in the first sentence of 4.4.1 is also wrong and a hostage to fortune. Finally, I note that there is no cross-reference to B.1 and B.2 for the deleted features. COMMENT: Likewise, "Nature of obsolescent features" is wrong. We made FORALL obsolescent, but the replacement DO CONCURRENT was only added in Fortran 2008. ACTION: Revise 4.4.1, 4.4.2 Nature of deleted features, and 4.4.3. Delete hard-coded numbers; such details are adequately dealt with in Annex B. Use more vague language "previous Fortran standards" rather than specifically mentioning the ones in question; such details are adequately dealt with in Annex B. Add references to relevant subclauses of Annex B. COMMENT: B.3.1 opening sentence is a lie - FORALL did not even exist in Fortran 90, let alone DO CONCURRENT. ACTION: Revise B.3.1 opening sentence. Done. 16-214r1: Done. 16-170r2: [576:14] Also hyperlinked+indexed "pointer", "pointer association", "dummy argument", and indexed "procedure pointer". Done. 16-172r2: Done. 16-173r1: Done. 16-197r2: Done. 16-221 section 3 only. [78:6] "with an assumed-rank dummy argument with the same" -> "whose dummy argument is assumed-rank with the same". (avoids double "with"). Done. 16-222: These editing instructions leave a great deal to be desired (not even close to the guidelines). I probably got it right this time though. Done. 16-178r2: [177:25] Also indexed "synchronized execution" here. Also hyperlinked "FORM TEAM" statement in this sentence. Also, added the cross-reference (8.6.9), which is to "FORM TEAM statement", immediately after the words "FORM TEAM statement", COMMENT: The indexing of "synchronized execution" is not useful unless we index it everywhere appropriate. I think that would probably be a good idea, I await advice. Deleted UTI 17 as I agree this is sufficient to resolve the issue, even without the (desirable?) indexing mentioned above. COMMENT: An unrelated issue: an EXIT statement is permitted to belong to a CHANGE TEAM construct, but surely executing EXIT does not mean executing the END TEAM statement? That is, there is a contradiction between the EXIT statement semantics and CHANGE TEAM. ACTION: Check for EXIT status and potential contradiction. Done. 16-179r1. Deleted UTI 20 as instructed. Done. 16-180r2: [133:14-16] REJECT. [135:2-4] REJECT. [137:12+] REJECT. Sorry guys, but it is not acceptable to have the effect of an ALLOCATE or DEALLOCATE with no STAT= specifier described in the subclause about the STAT= specifier only. The reader of the standard will not find it there. [137:4] "STAT= specifier is assigned the value of the named constant" ->"\si{stat-variable} becomes defined with the processor-dependent positive integer value of the constant" "in the intrinsic module" -> "from the intrinsic module" (more similar to wording in preceding sentence; I note that if detecting image failure is possible STAT_FAILED_IMAGE is indeed required to be positive) "the allocations or deallocations shall be performed" ->"each \si{allocate-object} is successfully allocated or deallocated" (previously wording could have been misinterpreted as a requirement on the user program; it is clearer to state the semantics, and avoids need for later weasel words.) [137:6] (second one) Totally different edit, "In either case" -> "In any case". (this is crystal clear after the 137:4 wording fix) Deleted UTI 16 as I agree this resolves the serious technical issue. COMMENT: I wonder if STAT_FAILED_IMAGE should always be negative anyway, as it is a sort-of halfway house "error, but everything succeeded on the active images". With a value of -1 indicating that image failure is not supported. Done. 16-182: Deleted UTI 30. Done. 16-183: [427:27-28] "argument TEAM" -> "TEAM argument" (the name always precedes the word "argument"). TECHNICAL CHANGE: "shall be present" -> "shall appear" (this is to disambiguate the syntax, using a runtime quality is unnecessary and I think inappropriate). Deleted UTI 29. Done. 16-184r1: Deleted UTI 28. Done. 16-185r2: [337:12-16] "A successful" -> "Successful" (reads better). "shall be invoked ... on all images" ->"shall be invoked ... on all active images" i.e. the 1st sentence of p2 is moved to p1 WITHOUT CHANGE. Otherwise stopped/failed images cause non-conformance, not an error condition - see next set of rejections. [337:19] REJECT. This change would make a program where one image in a team executes a STOP statement, or fails, when the other images in that team are invoking a collective subroutine, not standard conforming. Contradicting paragraph 7 which says that those situations raise an error condition. [337:24] REJECT. Same reason. STOP/FAIL raise error conditions, so this requirement does need to be limited to the active images. UTI 27 IS NOT DELETED. Its complaint that the description of STAT_STOPPED_IMAGE does not accord with the description of collective subroutines is still correct. The proper fix is to rewrite the description of STAT_STOPPED_IMAGE so that it no longer erroneously specifies that it means there was a synchronization required with a stopped image! As far as I can tell, the description of collective subroutines is in fact correct, viz it is what we want it to be. Please do not attempt to "fix" that to be something we do not want it to be! I have modified UTI 27 to make it more obvious what it is complaining about and how to fix it. ACTION: Rewrite STAT_STOPPED_IMAGE. Done. 16-206: Deleted UTI 22. Done. 16-211r1: In fact 16-007r1 included all the edits from the TS to this subclause, the TS itself was missing a necessary edit. [179:19] INSTEAD "executing " -> "execution of the construct". COMMENT: This relies on p2 where we say that image failure completes execution of the construct, which is pretty subtle. We could make it more emphatic by saying something like "has completed executing \si{block} or has failed" instead of "has completed execution of the construct". EXTRA EDIT: [179:20-22] "If image T is the next to execute the construct after image M, the segment on image M precedes the segment on image T." ->"If image M completes execution of the construct without failing and image T is the next to execute the construct, the segment on image M precedes the segment on image T. Otherwise, if image M completes execution of the construct by failing, and image T is the next to execute the construct, the previous segment on image M precedes the segment on image T." EXTRA EDIT: [180:1+1-2] NOTE 8.6, first sentence after "CRITICAL construct" insert "without failing", after "another" insert "nonfailed", making that sentence read "If more than one image executes the block of a CRITICAL construct without failing, its execution by one image always either precedes or succeeds its execution by another nonfailed image." TECHNICAL CHANGE: Both of those extra edits are, technically speaking, changes with technical effect. OTOH what the standard was saying was technically impossible... ACTION: Review wording to make sure I got it right. UTI 18 deleted. Done. 16-215r1: Done. 16-220r1: Done. 16-177r2: Done. 16-193r2: [7:25 1.3.44 corank] COMMENT: This now reads somewhat strangely. [10:9 1.3.67.4 elemental procedures] The edit commented "order is reversed because simply appending "(12.8)" might be construed to contain an explanation of elemental intrinsic procedures" DIFFERENT: added reference to the end without reversing, because 12.8 does in fact apply to elemental intrinsic procedures (it itself claims that it does, and 13.1 directs you to 12.8 for the semantics of elemental intrinsics). So such a "construing" would be entirely appropriate! [10:15 1.3.67.6 elemental subprogram] cross-reffed to 12.8.1 instead, as the rest of 12.8 is irrelevant [11:29 1.3.84 IEEE infinity] REJECT. The suggested cross-ref contains little useful info, the correct ref is to refer to the IEEE std, which this already does. [11:32 1.3.85 IEEE NaN] REJECT for the same reason. [12:9 1.3.89 implicit interface] REJECT. The interface also does not include whether the procedure is RECURSIVE or NON_RECURSIVE. Rather than replace one deficient definition with another, I think this needs further consideration. Perhaps something as simple as "that does not specify all the procedure characteristics" would suffice. [13:33 1.3.100.1 argument keyword] RECONSIDER. I did this against my better judgement, as I do not think that the BNF reference to where they appear in the syntax is particularly useful - argument keywords are discussed in many places. This should be reconsidered, maybe 12.5.2 is better, maybe no ref at all would be better. [13:36 1.3.100.2 component keyword] RECONSIDER. This seems unnecessary as "structure constructor" is already hyperlinked. Also a ref to 4.5.10 would probably be better than the BNF ref. [13:42 1.3.100.4 type parameter keyword] REJECT. This is totally wrong as type parameter keywords include KIND and LEN for intrinsic types as well. If any ref is needed, maybe 4.2. Or as we now call it, 7.2. ACTION: Review REJECT, RECONSIDER, DIFFERENT and COMMENT items. Done. 16-194r2: [41:3 2.5.1p1] REJECT. (1) Clause begins "such as ...", so I reject any attempt to make this into some kind of complete list. (2) These are all unqualified names. A "structure component" is not an unqualified name. So it is different in kind from the other examples. [41:20+ 2.5.4p1+] "target to be referenced by a reference to" ->"target to be denoted by" since it is not just referencing COMMENT: We have "permits", "causes", "allows" and "causes" as the active verbs for what is basically the same idea. It might very well be a good idea to pick one of these, and preferably not "permits" as it is not talking about the standard permitting something, and use that throughout. [42:3+2 NOTE 2.14] "\cf{exit()}" -> "exit()". 2.3.7 uses plain text for this, code font is not required. Done. 16-200r1: [92:1-2] Done, but it is moving from one suboptimal position to another. Obviously (?) proc-language-binding-spec should not be buried in "Function subprogram", but should be its own subclause at the same level. Maybe including all the other prefix and suffix items, maybe not. [97:5 5.5.8.2p2] Also indexed as per usual when hyperlinking. EXTRA SIMILAR EDITS: [103:19,21,23] hyperlink/index "local variable" thrice. [100:22,26 5.5.10p3] defective instructions... COMMENT that is p3 and p4, and thus "twice". ALSO hyperlinked/indexed "procedure pointer" Done. 16-201r2: [129:21+ C628+] DIFFERENT - omitted unnecessary BNF quali. [132:7-10 6.7.1.1p4] REJECT - this is not doing what it claims to do, since the remainder of the paragraph does not contain the quoted text, and this is not called out as a Technical Change. [132:32 6.7.1.2p3] REJECT - too ambiguous and hard to read. Existing text seems fine. Moving the second sentence before the first would use "those images" without any context having been established. [133:5-7 6.7.1.2p8] COMMENT - I deleted the redundant text, but it clearly belongs here, not in 6.7.1.1, as it is about execution not form. Done. 16-210r1: [290:10] Indexed "ultimate entity" as a definition. [290:17+] Indexed "use path" normally (i.e. not as a definition). Done. 16-216r1: [185:24] 8.1.7.5 Additional semantics for DO CONCURRENT constructs, para 3, also hyperindexed some things. Done. 16-224: [181:37] 8.1.7.2 Form of the DO construct, C828, Also "attributes"->"attribute" earlier in the sentence, also hyperlinked various terms. Done. 16-226r1: [92:18-19 5.5,3p1] DIFFERENT - did a completely different edit because the one in the paper was alternately redundant and wrong. Yes this means that subclause does not contain any list of times when allocation occurs, which is a whole lot better than an incomplete list. (Even a mere pair of parentheses can result in allocation, so please do not even attempt to be comprehensive, it is just a hostage to fortune.) Done. 16-225r1: REJECTED. [199:4-5] Unlike the current text, this does not establish that the expressions within an image control statement are part of the previous segment. COMMENT: That this second sentence contradicts the first (by changing its definition of what a segment is) is unfortunate, but the edit does not address that issue at all. Indeed, the paper does not even attempt to explain what is unsatisfactory about the existing text, so I can only ascribe its unanimous consent vote to Meeting Fatigue. COMMENT: Rewording the entire paragraph to give a clear and consistent definition of a segment will likely require more verbosity, but should not be too difficult. [337:16-19] This change would make a program where one image in a team executes a STOP statement, or fails, when the other images in that team are invoking a collective subroutine, not standard conforming. Contradicting paragraph 7 which says that those situations raise an error condition. COMMENT: Also, the edit is more opaque than the current text. Done. 16-181r1: [337:17] DIFFERENT. The edit being unnecessarily verbose, making the sentence more complicated, instead I simply changed "and" to "and/or", which seems to achieve the same effect (making it harder to misread). Deleted UTI 26. Done. 16-223: Done. 16-203r2: Improved spacing at the bottom of tables 7.2 and 7.9; these seem to be the only relevant ones in this clause. ASIDE: This is one of those "LaTeX" things, where everything you think ought to work has no effect (or peculiar effects) and the only thing that works reliably is manual addition of spacing. Which really ought not to be the case! Done. 16-212r1: [175:11] Merged interaction with another paper which moved a sentence from p1 to p2. [177:2] "Names" -> "Named construct entities (16.4)", After "associated" inserted "(16.5.1.6)", "scoping unit" -> "containing scoping unit" [since there is no scoping unit yet being discussed], Inserted missing comma before "in the same way". Moved the rest of the insertion to follow the BNF rules and constraints since it is giving semantics for those rules. "The associating coarray"->"Each associating entity" (There are 0-N of them so "The" is inappropriate, and our term is "associating entity"). "the selector" -> "its selector" (again, can be more than one), "the associating entity" -> "the associating entities". COMMENT: This last para could actually be in the "Execution" part, since in the process of giving the semantics of the syntax, it is giving info about what happens at run time. Indeed, for the other constructs it is in their Execution part... [177:8,19,22,23] Rewrote to use the BNF term "selector", since that is what is required to make 8.1.3.3 work! [178:1-5] "The associating coarray" -> "Each ", as you cannot require the associating entities to be anything at all before you start executing the CHANGE TEAM construct! "be established"->"be an established coarray" (use the term). UNANNOUNCED TECHNICAL CHANGE: This edit introduces a new requirement, that the program not branch to the END TEAM from outside the construct. I could not find this restriction in the coarray TS. ACTION: Review and decide whether this new restriction warrants mention in the Introduction, as a departure from the TS. [507:9] REJECT The current reference is not wrong, and works whether the attr stuff is in .1 or .2 (for the other constructs it is usually in the "Execution" part, so we could consider changing this one). [510:9] DIFFERENT Instead, deleted the whole sentence and added "or CHANGE TEAM" between "ASSOCIATE" and "statement" in the preceding sentence. [522:36] DIFFERENT Instead, deleted this whole item and added "CHANGE TEAM," after "ASSOCIATE," in the previous item. Deleted UTI 019. Done. 16-207r1: The problematic "since execution last began" is still in CHANGE TEAM, twice, so this UTI is not fully resolved by this paper; but looking ahead I see that 186r2 does try to finish that up. I will defer deleting UTI 023 until I have processed 186r2 and confirmed that it does fix it. Done. 16-231r2: [xix: bullet 4: 6] These instructions are opaque. Please quote the beginning of the sentence, not make me count them. I omitted the definite article. [xix: bullet 4: 13] Also hyperlinked STAT= and TEAM= in same sentence. [19:40] Also hyperlinked "images" in this definition, twice. [35:3] The point about "new team" was that the only team which exists at the start of program execution does not have a parent team: that is, only new teams do. [36:5] DIFFERENT there is no such thing as "invocation" of a statement! Instead, added "or event variable" earlier in the sentence. [130:4] REJECT this is ambiguous; do you mean "part of a variable" or "is a variable"? Also, and more seriously, what is so special about an assignment statement? Do you not mean "variable that is being defined"? BTW in a[i,STAT=istat]%component, the image-selectored thingo is not a " in an assignment" nor is it quite a "variable that is being defined", so probably "variable that is being defined or partly defined"??? ACTION: More work needed to sort out the [130:4] issue. Done. 16-228: Inserted the new subclause right at the beginning of Annex C. Some minor rewording. Hyperlinked and indexed lots of things. Done. 16-229: [75:16+] Also hyperlinked "module procedure" in C470. Done. 16-233r1: 3rd [84:7] Did not insert an extra "the". Done. 16-236r1: Done. 16-232r1: No edits in this paper. 16-235r1: Done. 16-191r1: Done. 16-195r1: [49:26] Also deleted spurious paragraph number on next line. Done. 16-213: Done. 16-217r1: Done. 16-219r3: Done. 16-234: [156:17-18] Looking at the item before this one, item (5) looks like it is also redundant, being covered by item (4). ACTION: Check to see if item (5) can also be deleted. [185:19] I already did this earlier. Done. 16-176r1: COMMENT: 176r1 is not the editor's report (that's 176). This is very misleading and entirely unhelpful. I saw no edits in this paper so voting on it was not productive - few if any will have read the badly formatted comments that were added. Done. 16-237r1: [207:25] I did this edit, but it still does not completely fix the paragraph. I believe that we need to have the segment before the LOCK statement on the failed image preceding the segment before the LOCK statement on the newly-acquiring image. (Also the new first sentence wording is not wrong, but is slightly odd. Re-wordsmithing it might be a good idea.) ACTION: Add missing segment ordering. [337:24+] DIFFERENT The new note does not strongly pertain to the immediately preceding text, so I added it at the end of the subclause, in accordance with ISO guidelines (and good style!). [379:19-23] REJECT. This does nothing other than add a lot of verbosity, which can only increase confusion. It is 100% completely unnecessary. Whatever team is specified on this call has no bearing whatsoever on the list of images known to have failed, it only has bearing on which known failed images the user gets told about. [424:24-27] REJECT. Again, flatulent and confusing redundant verbosity. [437:31-32] REJECT. This is simply factually incorrect. COMMENT: The paragraph being edited here is already a duplicate requirement of things specified elsewhere. ACTION: Either delete this paragraph or change it to "...is assigned as specified in 8.something and 13.something". COMMENT: UCOBOUND is specified to return the wrong value for the upper cobound, potentially outside the limits of the current team. Surely shome mishtake. Done. 16-186r2: COMMENT: Looking at the text, it seems obvious that "implicit synchronization" should be indexed wherever it appears in the standard; this is 9 times, in c5, c6 (3 times), c13, and c8 (4 times). Maybe we should do the same for "segment"? [177:28] "the team that was" -> "the original team that was"; a little clearer to use "original team" here as well as later. [178:10-19] Reworded first sentence of what is now para 6, to use language more like what we use elsewhere. COMMENT: I wonder if we ought not to remark that "If any other error condition occurs, there is no implicit synchronization."? Deleted UTI 021. Deleted UTI 023. Done. 16-208r2: [209:1-9] Broke first replacement para in two and massively simplified. Removed ambiguity with STAT= specifier in image index in an image control statement, by using sync-stat BNF. Absorbed all successful STAT= into the new first para; I thought of excluding CRITICAL because of its inconsistency, but decided to do it this way anyway. Removed "set" language; if we're not doing set operations, we don't need a set (just talking about the involved images is sufficient). Restructured error handling specs into a bullet list to make it clearer. COMMENT: I am not sure why it is so important to exclude STAT_FAILED_IMAGE and STAT_STOPPED_IMAGE from EVENT WAIT and SYNC MEMORY, but not to exclude STAT_LOCKED_OTHER_IMAGE et al. TECHNICAL ISSUE 2: CRITICAL STAT= can only catch image failure, but people will expect and require it to catch other error conditions (operating system provided critical sections often have multiple error possibilities). TECHNICAL ISSUE 2: An example of an error that might occur and which might be detectable and which might therefore be good to return would be the unexpected resurrection of a failed image (e.g. if someone tripped over a network cable and then plugged it back in), since that would cause very strange things to happen. TECHNICAL ISSUE 3: Contradiction with unreplaced LOCK/UNLOCK STAT= semantics in old para 3 (now p6). UNRELATED ISSUE 4: "8.6.5 SYNC MEMORY statement" only provides sync (p2) for actual SYNC MEMORY statements, not things that "have the effect of". This is a minor contradiction which should be corrected sometime. This could also improve the wording e.g. "performs a memory synchronization (ref)" is a lot better than "has the effect of" which implies no other effects occur. TECHNICAL ISSUE 5: I am surprised by the change of semantics for SYNC ALL and SYNC IMAGES. Previously, error conditions did not have the effect of SYNC MEMORY except for STOPPED. (The others for which this is true, CHANGE TEAM et al, did not exist previously.) TECHNICAL ISSUE 6: I do not understand why we can now do SYNC MEMORY in the presence of random operating system errors but not in the case of a mere failed image. In fact given our semantics of image failure, this one looks like it ought to be SYNC MEMORY-able even if you cannot do it for random o.s. errors, i.e. the opposite. COMMENT: I would think the solution for 5-6 is to provide SYNC MEMORY for both STOPPED and FAILED, and to continue not to require the processor to magically provide SYNC MEMORY in the face of o.s. errors. (The only "user errors" I can see here are ones that already make the whole program execution non-conforming...) COMMENT: It's a pity we did not require STAT= to appear when ERRMSG= appears, as it seems to be contradictory or at least a waste of time to define the ERRMSG= variable while error terminating the program. Still, water under the bridge now. TECHNICAL ISSUE 7: Why does an error condition in CRITICAL not error terminate the program when no STAT= appears? Surely shome mishtake? If an o.s. error occurs the only choices are to treat the CRITICAL as "advisory"!!! or to hang, or to terminate. It is likely that existing implementations that detect errors during CRITICAL will terminate (undetected might do anything). I would think that the normal reasoning - that if an image fails during CRITICAL the data structures will be left in an inconsistent state - means that error termination is the right thing to do... TECHNICAL CHANGE: I went ahead and did this rather than obfuscate the error termination wording with "except for the CRITICAL statement". [209:20-26] Deleted "If the processor has the ability to detect that an image has failed," and reworded the remainder; if the processor cannot detect image failure, *Then The Image Does Not Fail By Definition*. We do not need weasel words sprinkled to handle this case (and I am sure we should delete some we already have). After "does not contain the STAT= specifier" inserted "in a \si{sync-stat}". Replaced great long list of statements with "image control statements". This fixes TI7 above. The listed statements were (apart from CRITICAL) all the ones with STAT=. "the processor shall assign an explanatory message to the specified variable" -> "is assigned an explanatory message, as if by intrinsic assignment" "processor shall not change the value of the variable" -> "definition status and value of errmsg-variable are unchanged" These are the words we use elsewhere, people should be finding them and using copy-paste (I won't *always* spot an inconsistency in wording). TECHNICAL ISSUE 8: Surely END TEAM (STAT=fred) getting an error will still reset the team? This says that it does not, having the effect of SYNC MEMORY instead. Deleted UTI 25. Inserted UTI 31. Done. 16-209: COMMENT: I doubt that the wording should be "The segments ...", but that is a mere wordsmithing nitpick. Deleted UTI 24. Done. 16-227r1: [clause 1] New clause title revised (extra comma, lower case). [92:16+something] EXTRA "for use association" -> "by use association" in next sentence. [160:24+something] EXTRA throughout this note and the next, indented code fragments by seven spaces (as I have been doing elsewhere) instead of three. [552:2] EXTRA: hyperlinked some terms around here. COMMENT: The second failed image example in Annex C has a nonsense intro. ACTION: Rewrite this intro. [559:5-6] COMMENT: Paragraph 5 of (previously C.6.5) "Asynchronous input/output" is not grammatical, and the overall structure of p3-p5 is unsatisfactory. ACTION: Rewrite p3-p5 to improve exposition and make it grammatical. [elsewhere] EXTRA: Reworded remaining "must" in three notes in new clause 15. Done. Corrigendum 4 (working from N2103): [xv] F08/0121 already applied. [xv] (new in N2102) done. [xvi] F08/0131 done with slight rewording. [xvi] F08/0127 omitted as this was unimportant. [xvi] F09/0139 done. Note: Changes to the Introduction applied to C.1. [6:7+] F08/0124 already applied. [24:11+] F08/0147 and F08/0141 done. [52:6+] F08/0129 rewrote to reflect current TYPE wording. COMMENT: Maybe a good idea to review the wording of both. [70:3] F08/0145 done. [90:15] F08/0115 done. [102:9] F08/0122 done. [102:11] F08/0122 done. [111:13-14] F08/0101 done. [119:13] F08/0124 done. [127:8-9] F08/0109 also deleted EVENT_TYPE from this constraint. [127:9+] F08/0109 also included EVENT_TYPE in this constraint. [127:18-19] F08/0109 also included EVENT_TYPE in this para, also modified to fix new wording. [128:15-17] F08/0130 modified to deal with new wording etc. [129:8] F08/0133 already applied. [131:17-19] F08/0130 modified to deal with new wording etc. [132:4] F08/0112 done. [132:22] F08/0112 done. [150:28+] F08/0104 done with hyperlinking instead of references. [151:7-8] F08/0126 done. [152:7-8] F08/0104 done with hyperlinking instead of references. [153:25-28] F08/0140 already done. [157:14] F08/0147 done. [157:16] F08/0147 "have the same shape as" -> "be conformable with" TECHNICAL CHANGE: This was a mistake in the Corrigendum. [170:19] F08/0118 omitted "the" after "neither". [171:12] F08/0118 also fixed an article. [172:13+] F08/0119 done. [173:21+] F08/0119 done. [178:16+] F08/0144 added as a separate para before the other i/o stuff. [184:13] F08/0118 omitted "the" after "neither". [190:5+] F08/0134 omitted the unnecessary BNF ref. [190:16-] F08/0113 done. [194:6-] F08/0113 done. COMMENT: This requirement is currently missing for the EVENT statements, also FORM TEAM (and CHANGE TEAM?). ACTION: Extend requirements as necessary. Perhaps "The stat-variable shall not depend on the value of any variable that might be defined in the same statement. No other variable in a statement shall depend on the value of the stat-variable." [195:2-] F08/0113 done. COMMENT: I wonder if some of these ought to have ", in the same statement" appended. I also wonder if it should be "a stat-variable" to cover other side-effects, or if that's already handled by some generic statement. Also ditto comment for [194:6-]. [275:18] F08/0142 done. [281:25-28] F08/0132 done. [282:7] F08/0100 already covered by new constraint C1516. [282:14] F08/0100 ditto. [295:3] F08/0135 done. [295:4+] F08/0122 done. [295:6] F08/0136 done. [295:9] F08/0136 done. [295:13] F08/0136 done. [300:14] F08/0117 done. [300:22] F08/0117 done. [311:34+] F08/0141 done. [312:23+] F08/0143 done. [312:35] F08/0148 done. [330:20] F08/0103 done. [330:22] F08/0103 done. [368:26] F08/0102 done. [372:18] F08/0106 done. [372:19] F08/0106 done. [389:4-5] F08/0123 done. [393:18] F08/0137 done. [399:17] F08/0109 also applied to EVENT_TYPE. COMMENT: I think that "subcomponent" in both those constraints should probably be "potential subobject component". As a rule of thumb, constraints should be using the latter, since "subcomponent" is a concept with a runtime dependency. [408:1-] F08/0104 done. [418:16] F08/0104 done. [418:32] F08/0104 done. [420:4] F08/0104 done. [426:19] F08/0104 done. [428:9] F08/0104 done. [428:21] F08/0104 done. [436:15] F08/0116 done. [436:16-19] F08/0116 done. [440:4] F08/0120 done. Done. ===END===