J3/06-293 To: J3 From: Malcolm Cohen Subject: Editor's report on J3/06-007r1 production Date: 2006/09/21 1. Introduction This report describes all the changes made in producing the 06-007r1. Most of these changes come from meeting papers; others are purely editorial. 2. Internal changes - Update PDF/nonPDF output detection macros and move to j3.cls (removing from 007.tex), including the output dependent hyperref package setup. In hyperref.sty, make the hyperlinks less garish (in particular, black). - Update hyperindex.f90 to get the hyperlinks right in the index (off by 2), and to be able to process index entries in the front material (i.e. the pages with roman numerals). - Fixed a number of undefined references. - Use the underscore package, plus babel, and change \_ to _ everywhere. 3. Meeting papers from 177 - 06-274r2 item 2 spacing between rules: deferred to later (low priority). Added UTI 080 as requested for the laundry list. [1:12] "part 2" -> "this" ("part 2" is not an ISO-conformant ref, but the sentence is talking about it anyway). [2:40] Reorganised 2.2 and made the ref to the (new) 2.2.1. [6:2,3] Done. [65:17,18] Done. [76:34] Done. [15:13] Done. [41:22] Also deleted "a", and changed "the value" to "it". Editorial suggestion: deferred to later (low priority). [42:note 4.1] Also capitalised "the". [44:1] Done. [44:30] Done. [53:note 4.14] Done. [54:26] Done. [54:28-29] Done. [64:note 4.34] Reworded explanatory subclause to make it simpler. [65:27] Did the "and" insertion, deferred the movement (looks complicated). [115:9] Done. [115:12] Done. [126:16] Added UTI 081 as requested. [131:note 6.31] Done. - 06-275r2 There were no edits left in this paper. - 06-192r1 [175:19-21] Deleted paragraph, clause 2 consideration deferred. [175:22-23] Done. [176:2-3] Done. [176:10-11] Done. [176:12-16] Also deleted no-longer-forward reference, and changed "single statement" to "single action statement". [177:5] Done. [178:2-3] Done. [179:13] Done. [179:14] Done. [181:30-31] Done. [182:2-4] Done. [184:2] Done. [185:7-8] Done. [186:29] Done. [187:23] Done. [187:36] Done. [188:10] Also changed "refers to"->"contains" in the text at [188:14]. [188:25] Done. [189:10] Added the constraints at [189:9-] instead, and inserted "additional" after "following" at [189:9]. [191:4] Replaced since there is no , left an indefinite article before " appears", also changed "refers to"->"contains" at [191:6]. [191:16] Instead, "a block"->"an executable construct"; we already have lots of (declaration) constructs which can contain declarations. [191:29-32] Done. [192:13-14] Done. [176-193] Done. [Subclause 8.5] Done. [203:12] - 06-231r1 [499:28+] Done. Fixed the LaTeX at [499:35] to be automatic rather than hard-coded. [499:37] Did nothing - this is an automatically generated cross-reference. [500:8+] Perhaps the note belongs after 16.15, but I added it before anyway. The suggested note seems substantially worse than my suggestion. I deleted the assignment of a specific value to Y - this was spurious since the specific value was NEVER referred to. I reinstated the elipsis between the declarations and the code. "is true" (twice) adds nothing except toner to the paper, but I've left it alone for now. My example worked on all machines, whereas this one only works on 32-bit (n.s.u.) machines!!! What on earth are people thinking? That it is GOOD to be nonportable???! I've left this alone for now, but I recommend that the next subgroup review it and fix it. It says "endian convention for the processor's memory", but in fact multiple machines have endianness artifacts elsewhere as well (for example, the x86-32 register set has visible endianness). I've heard many times the claim that endianness is only about memory ordering, but that IS JUST NOT TRUE. I've left this alone for now, but I recommend that the next subgroup review it and reword it. More seriously, the paper purported to fix issue 75 but did nothing of the kind. The meaningless normative text is still there. I recommend that this meaningless normative text be struck. Modified UTI 075 accordingly. - 06-233r1 [500:7-8] Omitted the commas from the edit. The paper purported to fix issue 77. Well, it's definitely improved it, but the basic issue is still that it is expanding the obsolete concept of storage association. Why should I be able to EQUIVALENCE my little-endian and big-endian integers just because they have the same storage size. (Or binary and packed decimal, or etc.) If that is not what it is saying, just delete the offending paragraph since it is otherwise saying nothing. If that is the intent, I wish to object in the strongest possible terms. It's not necessary to add anachronistic junk to the standard to accommodate dusty decks. Furthermore, it directly contradicts item (7) of the storage association list. Furtherfurthermore, it contradicts our intent as expressed in at least one interp request, where we said (effectively) that padding was allowed in COMMON blocks. Saying that a whole bunch of objects all occupy the same amount of storage is going to remove that ability. Vendors do different amounts of padding (thus taking up different amounts of storage) for different types and objects right now, and it is highly desirable to allow that to continue. Modified UTI 077 accordingly. - 06-234 [538:33] Also deleted the comment on this line. - 06-271 [487:10-] I've done this here, since it keeps the list in reference order, but it really is pretty irritating that the first list item is not the most usual one (names). There never has been any good reason for making images more important than life itself, and this just underlines it. [487:20] Done. [487:29] Rejected. This is said elsewhere. It does not belong here. [513:19] Done. Deleted UTI 078. I'm not entirely happy with the reply, or (mostly) with the removal of global i/o units (it almost certainly makes co-arrays less efficient on SMPs), but that removal makes my question moot. - 06-213 [44:31-32] Done. [271:18] Done. [312:3+] Also deleted back-ref at line 6. [510:10+] Done. Deleted UTI 014 and 015. - 06-255 Also changed a number of cross-references; mostly either to the new "Ordinary dummy variables" or to 12.5.1 (i.e. up one level). Noticed that auto-targetting has not been integrated with Annex C; added UTI 082 about that. - 06-215 [45:1-4] Done, along with moving attached UTI 017-019. [490:3] Done. - 06-217 Removed UTI 019. - 06-235r1 The paper states "In earlier standards there was only one image, so oversubscribing the word "program" to also be the executable was harmless. That is no longer true." I don't have a clue what you are trying to get at here, other than maybe some attempt to get out of defining program execution. Well, I don't accept that. "images needs to be the first thing" Yes, I'm familiar with the claim that parallel execution is more important and fundamental than serial execution. I don't buy that one either. [14:4+] I called the new subclause "Program execution" instead. "available to"->"available on"; "to" is only for action, not state. "executable instance"->"instance". Would it really be that onerous to give page/line references, as we require, for the movement of the Notes? from [17:5+0-end] Done. from [18:3+0-3+5] Done. from [18:4-6] Done. [14:6] Done. [15:7] Rejected - existing text is fine. ...there is nothing wrong with talking about termination of execution of the program, and indeed one hopes that does happen! Your first edit established that this is ok. [15:11] Rejected; it is unacceptable to have no definition of program execution. I've inserted an attempt to do this. [16:3] Superseded by 06-236 below. [17:1 - 18:6] Delete the current 2.3.5, which was replaced by 2.3.1 above. Deleted UTI 001 and 002. [72:31] Done. [127:2] Rejected. Your first edit established that this is ok. [127:5-6] Instead, deleted "during the execution of a program". [127:20] Rejected. This statement appears to be true as is. [127:22] Rejected. This statement appears to be true as is. [127:29] Rejected. This statement appears to be true as is. [129:17] Rejected. Your first edit established that this is ok. [189:2] This edit was ambiguous, since "the program" appears twice on this line. However, the text being edited is junk - we "terminate" a DO loop on program termination, but we don't terminate a CALL on program termination. That's just silly. When a program terminates, everything stops. That's what it says in c02. We don't need to rush about undefining variables, deallocating memory, unwinding the stack, terminating active loops, type selection blocks, etc. I have fixed this by deleting this case instead. [255:22] Rejected. Your first edit established that this is ok. [255:40] Rejected. Your first edit established that this is ok. [256:17] Rejected. Your first edit established that this is ok. [379:1] Rejected. Your first edit established that this is ok. - 06-236r1 The paper states "We do not need the concept of 'termination of execution of the program'" In that case why did 235r1 have an edit to add "Execution of a program consists of the asynchronous execution of a fixed number (which may be one) of its images." that seems to establish the idea of executing a program quite effectively "but it may be considered to occur after the asynchronous termination of execution of all the images." indeed, according to your own text termination of the program necessarily involves termination of all images; the converse is maybe less clear, but probably true. [16:3-10] Done. [17:1-] Done. [196:16+] Done. [196:21] Rejected. Unless error termination counts as an "image control statement execution" (which it doesn't), the third option is still valid. [196:22] Rejected ditto. Deleted UTI 003 and 004. I've rewritten UTI 005 and 006 to better express the problems remaining, and since they are mostly about STOP, moved them to c08. If STOP is changed to terminate only the current image: - some of UTI 005 will become moot - some of UTI 005 might apply to STOP,ALL:: - all of UTI 006 might apply to STOP,ALL:: The new versions of these use the STOP,ALL:: terminology where appropriate. - 06-237 [21:18] Instead, changed "is declared with" -> "has". Co-rank is described only one paragraph down; it is preferable to say *what* a co-array is rather than *how* you get one. Also fixed the tail of the sentence to say that it can (not may) be *directly* referenced or defined from any image, since it has turned out that ***Virtually All*** variables can be indirectly referenced or defined from another image (making the previous version of this sentence seriously misleading). {Actually, my wording is a bit clumsy, but at least it doesn't mislead quite so much.} Split the paragraph after the second sentence. [21:20] Inserted "corresponding" after the first "set of", otherwise we seem to have nonsense. Rewording to turn a triple sentence into three short ones, and the potentially confusing "in the ... case" into ordinary conditions. "In the scalar case" -> "If a co-array is scalar". "; in the array case" -> ". If a co-array is an array". "; in both" -> ". In both". Indexed as "co-dimension" not "co-dimensions". Deleted UTI 007. - 06-238r1 The paper claims about UTI 008: "This note really is about the SAVE attribute and is needed to support the the (very short) constraint at [97:2-3]." No it is not - it is about why we don't have automatic co-arrays, and no it is not needed here. We don't have examples (with invalid code no less) for SAVEd namelists, macros, intrinsic procedures, dummy arguments, function results, ... We don't have anything here about default-initialized things in modules (which also happen to require the SAVE attribute). There is no need for this constraint to be here - it is a constraint on co-array thingos, not a constraint on saved thingos. It clearly belongs in the co-array thingo subclause. So I've moved it. On issue 10, the paper writes "save is required for a module variable if it has a co-array component. We wish to retain this since otherwise an unexpected implicit synchronization would be needed whenever the module ceases to be active." Why would that be unexpected? In any case, I don't believe anyone has implemented the licence to deallocate module allocatables, so we could remove it ... but since it is only a *licence*, not *mandatory*, we do not need to remove it. More importantly, this restriction is inconsistent with allowing top-level allocatable co-arrays in a module. (The edit to 97:3 did that; whether that was inadvertant I cannot say.) [97:3] Done. [97:3+] Done. [97:4-6] This edit was completely broken, since co-arrays don't need to be declared by a type declaration statement. (Yes, what it was replacing was broken too.) Rewrote it from scratch. Hopefully I got it right. [127:38] Rejected. Whether you mean to deliberately exclude recursive iterative refinement algorithms from using co-arrays or not, you don't want these edits. Maybe you mean to say "and they shall be at the same depth of recursion"; your current wording says that the statements *don't match* if they are at different depths, which forces the system to deadlock! Anyway, putting that restriction on would not help stack alignment, it just forces the user to push their ALLOCATE/DEALLOCATE statements out into additional internal procedures (their caller will not be at the same depth, but they will be). So (a) the edit is wrong (b) the restriction is onerous to the user (c) the restriction is unhelpful to the implementor. I strongly recommend not doing it at all. [131:10] Ditto. Moved UTI 010 and the constraint it is about into c11, along with the other requirement for SAVE-ing. In fact this constraint is close to trivially merge-able with the revised C1107; reworded to be more similar. Deleted UTI 008 and 009. Modified UTI 010. - 06-239 On "co-bounds", the paper claims the definition "should be restored to 2.4.6 so that the term 'co-bound' is defined early" Indeed, just like TKR (only less extreme), this merely puts the definition 70 pages before its first use. This is not responsive to my suggestion for the co-array attributes to have their own clause. [21:23] Rejected. This is not necessary or useful here. [88:24-26] Done. Left UTI 012, but the rest of it is actually fixed by the next paper. Note: I would not object to there being a sensible definition of co-bounds, but listing the syntax isn't sensible. Funnily enough, there is a readable definition in the glossary but not in normative text! - 06-240 This addresses UTI 012 as well as UTI 013, though it did not note that. [62:16] Done. [89:4] Done. [89:13-14] Done. [92:16+] Did not introduce "allocatable co-array" as a special term. (I don't believe it is used, and it has the obvious meaning anyway.) Rewrote the opening sentence. Made it a definition of co-bounds. Indexed it as singular. Removed BNF limitation on the first constraint. Rewrote the third paragraph not to contradict the second (think of the situation after an allocate-deallocate sequence). Yes, the existing text for deferred-shape arrays is wrong here. Reworded the fourth paragraph too (again, deferred-shape array text is bad). "Explicit-co-shape co-array". Rewrote the opening paragraph to make it a definition of co-bounds, indexed as singular; I left the term definition as this is used later and reads better than the alternative (a close call though). Removed the BNF limitation on the first constraint. Fixed the article in the first constraint. Made lower-co-bound and upper-co-bound into syntax item refs. Fixed "explicit-shape"->"explicit-co-shape" and "lower-bound"->"lower co-bound". [126:11] Done. Deleted UTI 012 and 013. - 06-242 [123:6] Done. [123:6] "sequence of co-subscripts" -> "co-subscript list". "sequence of subscripts" -> "subscript list". "is mapped to an" -> "determines the". "same way as a" -> "same way that a". "is mapped to the" -> "determines the". "position of the array element in array element order" ->"subscript order value". (the position is a position, not a number; the subscript order value is the number computed by the formula). The exposition was wildly at variance with any of the text around here, including the array element stuff it was supposedly emulating. Went back to [21:25-27] and improved the poor exposition there too. Deleted UTI 021. - 06-243 [57:7+] Done, with the second "the" -> "its". [124:28] Rejected - ungrammatical: it tried to forbid a from having co-array ultimate components, which did not do much because syntax doesn't have components anyway. Added a much-reworded version as a separate constraint instead. [124:34+] Added this before C638 (at [125:8-]) instead. Reworded. [125:18] Done. Deleted UTI 022. - 06-244 [157:16] Done. Deleted UTI 024. - 06-281 [109:21] Done. [110:1-] Done. - 06-193r1 [297:21-22] Done. [298:3-4] Done. [300:1-3] Done. [302:27-29] Done. (I still think the wording is clumsy though.) [302:30+2] Done. [306:4+] Done. Constraintification deferred to next meeting (no time now). [307:11] Done. [307:44] [310:1] Done. [317:5+2] Done. [318:20] Done. [318:22] Done. [319:40] Done. [321:4] Done. [322:16-17] [323:21] [327:28-32] Done. [327:41-42] Replaced "the function ... disassociated" instead. [329:19-23] Done. [329:29] Done. [329:38+] Done. [330:22+2] Done. [331:31-32] Rejected. "executable statement" is used lots in the immediate vicinity; it would be inconsistent to change it here and not at [331:36] for example. Added UTI 083 over the interpretation of this text. [332:6] Done. [332:19] Done. [333:7] Done. [333:28] Done. [333:33-34] Done. [334:7] Done. [335:2] Done. [336:8+1-3] Done. - 06-222r1 [c13, BIT_SIZE] Done. [c13, BITS_KIND] Done. [c13, LEADZ] Done. [c13, POPCNT] Done. [c13, POPPAR] Done. [c13, TRAILZ] Done. Deleted UTI 060, 062 and 065. - 06-226r1 [405:19] Done. [405:20] Done. [405: 20+] Done without "kind type" hyphenation. [405:21] "argument" -> "argument(s)". [387:15] Done without "kind type" hyphenation or the ellipsis, and with "are integer" -> "are of type integer". [390:3] Ditto. [392:5] Ditto. Deleted UTI 067 and 068. - 06-208r4 [475:19-28] Done. - 06-272r1 [478:Table 15.2] Done. [485:12] Done. [491:8] Done. [472:1+] Rejected. Sentence makes sense as it stands, and would not make sense after this edit. (I agree that "find it helpful" is poor phrasing, but repeating the tail of the sentence in the middle just muddles things up completely. The whole note should probably be removed.) [474:6+] Rephrased. Being a pointer is what it is, being a co-indexed object is how you got to it, so mixing the requirements just sounds wrong. [475:1] Ditto. [475:6] Ditto. [476:19,22] Rejected. This text was replaced by another paper. [479:1-] Done. [483] Done. [503:18] The added condition is only true for polymorphic associating entities, so I added that parenthetical condition. [503:18-21] Done. [497:3-19] Should these bullets be numbered? Similarly for [498:9-13]. Answer: No. ISO preferred style is for bullet/dash list, except when items in the list are referenced elsewhere. It's not a hard-and-fast rule, but it seems reasonable to me. - 06-276r1 [25:16-21] Done. [51:2+] Done. - 06-191r2 [145:8] Done to [145:1] instead. [145:1+] Done. [145:3-4] Done. - 06-198 [204:8-10+4] Done. Deleted UTI 037. - 06-256r2 (edits against 06-255) [316:27-28] Done. [316:28+] Done. [316:6] Done. [316:6-7] Done. [316:8-9] Done. [316:16-18] Done. (edit to 06-007) [312:3+] Done. (edits to 06-255) [312:2] Done. [312:4] Done. [312:16] Done. [313:1] Done. [313:6-7] Done. [313:8] Done. [313:9] Done. [313:12-13] Done. [313:15] Done. [313:18] Done. [313:21] Done. [313:23] Done. [313:27] Done. [314:12] Done. [314:14-15] Done. [314:18,19] Done. [314:21] Done. [315:3] Done. [315:15] Done. [316:15] Done. [316:20] Done. [317:1] Done. (edit to 06-007) [310:19-20+2] Done. - 06-194r1 [341:19,20] Done. [355:24-26] Done. [377:19] Done. [377:28] Done. [378:6] Done. [379:0+4-0+9] Done. [380:16] Done. [383:4] Done. [381:8,412:27,412:28+0-3] Done. [413:16] Done. [415:36] Done. [438:23-439:1-] Done. [441:7] Done. - 06-195 [188:4] Done. Deleted UTI 025. - 06-221r1 [163:3] Done. [163:4-5] Done. [164:21-22] Done. [312:5-6] Done without "associated" twice. [313:5,313:6-7,314:2,314:2-3] Done (differently, after 06-255) Deleted UTI 052 and 053. This fixes UTI 017, so I've deleted that too. (06-255 edits) [313:6] Done with "effective"->"actual". [313:11] Done with "effective"->"actual". [313:28] Reworded resulting sentence to make more sense. - 06-245r1 [194:13 - 195:17] Done with some rewording. Deleted UTI 026, 027, 028, 029, 030, 031, 032. - 06-247r1 [199:9] Done. [341:22] Done. Deleted UTI 035. - 06-248 [201:5-6] Done. Deleted UTI 036. - 06-250 [206:7] Done. Deleted UTI 038. - 06-224 [376:12-] Done with B'0'. Deleted UTI 064. - 06-225 [399:28] Done with "same as" -> "same as that of". [399:31,33] Done. [399:33+] Done. Rereading the description, I am slightly uneasy with the assumption that the physical representation of everything is a BITS value. But we've certainly made that assumption in a number of places. Deleted UTI 066. - 06-227 [418:27-28] Done. Deleted UTI 070. - 06-228 [346:23] Done. [426:24] Done. Deleted UTI 071 and 072. - 06-186r1 part 4 [230:17+2-3] Done. - 06-188r1 [14:1+] "[Does 2.3 need a new 2.3.1 for its first paragraph?]" The editor says yes, and I have done it (see editorial changes below). [15:Table 2.2] As well as this, I have substantially re-set table 2.2 as it was too wide. It also contained contradictions which I have attempted to correct. (Please ignore the ugliness caused by the unlucky page break; the page is very unlikely to break there in a future revision.) [15:13-14] Done. [15:21+] Rejected. This duplicates (using substantially different words) the text already in "BLOCK construct". I've added "in processor-dependent order" to that text, and replaced this insertion with a brief forward reference. [36:6-7] Fixed. - 06-205r1 There were no edits left in this paper. - 06-207r1 [56:11-] Rejected - definition doesn't recurse (the test recurses but the include components don't). Inserted one that does recurse, in the inclusion, and not in the test. Hint: the recursion to get direct components must be *EXACTLY* the same one as for ultimate components, the only difference is which components to include at each recursion (viz all of them, rather than only "leaf" ones). So I reworded it to use exactly the same words as for ultimate components, except for where the concept differs. While I was here, changed the "ultimate components" indexing to index the singular instead of the plural. [290:23] Reworded the constraint more drastically to make it hopefully readable. Note: "direct component" is a subset of "subcomponent", so it's ok to use the "default-initialized" term. [294:14] Done. [319:22] Done. Also inserted "direct" in a relevant paragraph under "Ordinary dummy variables". - 06-210r2 section 1 [xv] Done. [33:19] Done. [33:27] Done. [35:28] Done. [39:] Done. [65:2-3] Done. [65:27] Done. [88:17+] Done. [90:21] Added "nonallocatable" instead. [91:22] Done. [94:?] Done. [117:14] Done. [124:25,30] Done. [158:30] Fix the formatting problem with (upside down !?) - 06-212r1 [3:15-16] Done with rewording to make the sentence grammatical. [3:24] Done with grammatical rewording. [4:8] Done with grammatical rewording. - 06-220r2 [281:11] Did Zw.m instead, and replaced "w" with "w and m" later. [281:11] Did k/4.0 instead; if we are going to use Fortran instead of maths, we need this. Hmm, maybe we really should use maths here, since the Fortran version could have rounding or other things happen, and thus not be well-defined. [287:14] Similarly. [287:14] Similarly. Deleted UTI 048. - 06-223 I'm rejecting this entire paper. The whole point of default bits is that it interacts with default integer. Whether that integer has BIT_SIZE equal to NUMERIC_STORAGE_SIZE or not. For example, there have been implementations in the past where this wasn't true: default integer was entirely 16-bit ... stored as 32 bits *only in storage association contexts* ... in a number of F66 and F77 compilers. This paper effectively claims, tortuously at that, that NUMERIC_STORAGE_SIZE has to equal BIT_SIZE(17). Making this Technical Change to the standard is certainly not mandated by BITS support. I don't see any need to do this. If we *do* choose to do it, it should be done properly. That is, make it a straight-forward requirement rather than an obscure result of predicate- chasing. (And about half the edits of the paper go in the wrong direction on this.) Modified UTI 061 accordingly. - 06-219r2 [265:34-35] Done. Deleted UTI 045, 046, 047. - 06-230r1 [472:3-8] Done. [478] Done. [472:7-8] Done. [478] Done. Deleted UTI 074. - 06-232r3 [505:13-14] Done. [506:14] Done. Nice try, but no cigar. You've swapped the "bits don't define anything" problem with the "bits define far too much" problem. Modified UTI 076 accordingly. - 06-246 There were no edits in this paper. (1) On the substantive issue - that all data needs to be in remotely-accessible memory (that is, what has traditionally been technically known as *shared memory*) I accept this unwelcome news. So now, the only difference between a "co-thing" and an ordinary "thing" is that a co-thing is *directly* addressable whereas a non-co-thing is only accessible via a pointer. (Since the TARGET attribute can be added by argument association that's not much of a consolation.) That's quite a bit different from the advertising material for this feature (why should I be surprised) ... and we must be careful in the standard not to repeat the inaccurate advertisements, i.e. we cannot say (and we probably do already) that co-thinginess makes something accessible to other images, we need to say *directly accessible* instead. (We've already caught one example of this, but there might be more.) (2) On the notation issue, the paper expresses an opinion (but declines to give edits to change anything) that commas are preferable to arrows in the "NOTIFY-QUERY" notation (Bill and John were confused by the arrows). Well, the arrows were intended to convey how the information flows, that is precisely why notify *TO* and query *FROM* have the arrows in opposite directions. (Of course WAIT would be a better statement keyword than QUERY, we've already burned that bridge, or at least badly singed it.) Given no edits, I'm not going to change the notation (which I at least find easier to comprehend that the associated text). Admittedly, even after substantial wordsmithing of the notify-query stuff it is terribly difficult to follow (and it is a shame /B ran out of time to consider Aleks's paper 286 which attempted to improve that). After we've processed the next incarnation of that paper we can always revisit the notation issue if an alternative notation is thought to be preferable. Deleted UTI 034. - 06-251 This attempts to defuse UTI 039 by saying that i/o units are not global. References to the actual papers that made it so would have been useful (how can I otherwise tell if the issue is solved?). In any case, making the i/o units local does not address the issue of what the second sentence is trying to say. Since it is (allegedly) no longer saying something clever about connection across images, apparently it is saying something totally banal and nonsequiturious, like "the connection is for a file" or "for formatted or unformatted", or something. Deleting this addition (now just silly rather than contradictive) will resolve the issue. Modified issue 039 accordingly. - 06-267 [414:18+] Done. Deleted UTI 069. - 06-254r1 [127:29] Done. [127:26,28] Done, plus converted all three sentence pairs into dual sentences joined by semicolons. [129:23-25] Done. [129:27-28] Done with rewording. [129:29] Done. [142:14+] Done without wordsmithing. [191:20+] Added at 22+ instead. [191:27] Done. [498:24+] Done. [498:36+] Done. - 06-257 John and Bill write "The second sentence is needed for the case without a FILE= specifier." Malcolm replies: It would be a lot clearer what you were actually talking about if you said what you mean, which apparently is STATUS='SCRATCH'. [222:7] Done. I also reworded the second sentence to say what it means rather than require theorem-proving. Deleted UTI 041. - 06-261 [339:15] Done. Deleted UTI 056. - 06-262r1 [199:14-15] Done. Note to Editor: Index the defined term as {synchronization!implicit team}. ...Rejected. I have done {team synchronization!implicit} instead, because we have an index item for "team synchronization" but not for "synchronization". If and when we decide to index synchronization, we can do the suggested indexing in addition (not instead). In any case it should be indexed as itself at both definition and use, so I've done that. Close, most of a cigar, but ... the definition doesn't say what "the team" is. I added a definition myself rather than faff around with modifying the UTI. It's a bit messy, but seems to cover the topic ok. Deleted UTI 057. - 06-264r1 [339:18+] Done. [574:26-28] Done. [574:31+] Done. [574:33] Done. [574:33+] Done. [574:35] Done. [574:39,42] Done. [575:1,4,5] Done. [575:3] Done. Deleted UTI 058. - 06-265r1 Deleted UTI 059. - 06-266 The editor does not agree that this assertion has answered the UTI. "FORM_TEAM is a collective routine so that an implementation has the option of performing operations that involve all the team members." But the IMAGE_TEAM argument is the result of FORM_TEAM, not it's input. It cannot do anything team-clever with it until afterwards. This is *totally unlike* the other team operations, which operate on a team identified by an IMAGE_TEAM object. It is much more like SYNC IMAGES. FWIW, this goes back to how we identify teams. It would, I think, be more straightforward to say that a team is always identified by an IMAGE_TEAM - that would simplify exposition in a couple of places - and just to have a simple requirement on the execution of FORM_TEAM. I find that fits better intuitively with how people were saying that collective thingos were these communication-optimised operations, which obviously is not the case for FORM_TEAM since it hasn't been set up at that point. (I'd really like to be able to say "A <> is a set of images identified by an object of type IMAGE_TEAM", that seems to me to be an ideal way of defining teams that doesn't get all waffly and confusing about whether some arbitrary set of images is or is not a team.) - 06-252r2 [249:14+] Done. [254:17+] Done. [348:27+] Done. [432:18+] Done with some rewording. [438:24+] Rejected. Added a new subclause instead. Reworded to look more like the other constants. Deleted UTI 040. Added UTI 085 about ordering of image indices in these functions. Added UTI 086 about error handling in SYNC TEAM. Added UTI 087 about the lack of need for NULL_IMAGE_TEAM. Added UTI 088 about connect teams. - 06-270r2 [62:15+] Reworded from scratch, inserted at 17+ instead. [89:7+] Deleted "derived", inserted at 5+ instead. [118:9+] This edit was not integrated with constraint C616, so I added a new constraint after C616 for that part which could be. Tried to reword the second sentence to make sense. Added UTI 089 about the inadvisability of requiring things of subcomponents which are not checkable. Added UTI 090 about what kind of type IMAGE_TEAM is. The paper wrote "We update the content of issue 73 to be self-contained and refer to J3/06-007. We have also corrected an error in one of the edits." Actually, there were no updates to the content of UTI 073! Nor do I agree that UTI 073 is adequately answered; admittedly it is not properly explained. I've modified UTI 073 accordingly (UTI 089 and 090 cover some of it too). - 06-197 [Annex D] Changed "Section" to "Clause". - 06-199 [210:38] Rejected. The extra case is the topic of [211:16-17], and is inappropriate for the list at [210:33-211:2]. [211:4-5] Rejected. The answer to the first question is "maybe - that is not standardised". The answer to the second question is "not necessarily - that is not standardised". For example, it might take multiple octets to represent a record marker, so file storage units might contain only part of the record marker not all of it. Furthermor, some file storage units could contain padding ... in particular, on a system which pads records to a multiple of 4 octets without affecting the record length. Even within a record, indexing schemes could mean that some file storage units might contain information that is not a character. The whole point of the minimal requirements here is to permit wide latitude to the processor. [211:16] Rejected. The sentence is correct as it stands. The prohibition on other values is said elsewhere. [213:1-3] I agree that [213:9-10] clearly applies to non-stream access, but not that it clearly applies ONLY to non-stream access. To make that clearer, I've moved [213:1-2+3] *NOT [213:3] *!* to [213:10+]. I've also added a caveat to the note to the effect of that being the case only for nonadvancing output (for advancing output, the file is positioned after the record). [213:15-16] Rejected. Record markers are not values, they are part of the file structure. [214:28-29] Rejected. An internal file can be specified by a number in an UDDTIO routine. [216:8] Rejected. No it doesn't - an internal unit is connected to an internal file (as is already pointed out). [217:20-] Done. [219:29] Done. [220:16] Done. [220:27] Rejected. 9.5.3.4.2 is just as good an explanation, 9.10.3 is merely duplicative. [220:29+1-2] Rejected. See [25:19-21]. This does not require the character *designated* as blank to actually *be* a blank. [222:4] Done. [222:12+] Rejected - this needs to be a paper on its own with edits. (Also requires J3 discussion on the technical merits.) [223:10] Inserted "or unit" instead. [226:25-] Rejected - no suggested content. [227:17,19] Already done. [228:19] Done. [229:4] Rejected. It has other stylistic differences anyway. [230:16] Rejected. The sentence is probably ok as it stands, as long as "associated" is understood to include partial association in this context. The suggested edit is broken since it would apply to output lists as well as input lists. [230:26-27] Instead, I turned them all into a list. I also moved note 9.40 to immediately follow [232:1] which is what it is showing. An alternative might be to delete this uninteresting note. [231:16-19] Rejected for now. [232:1] Done. [232:24-233:13] Rejected. The verb is this sentence is "determine", and is already in the present tense. "has occurred" is a condition that IMO is correctly specified in the past. [233:1] Rejected. It's not pending until after it has been initiated. And we never hyphenate data transfer. [233:2-4] Rejected. This is talking about when it completes, [233:15-17] is about when the transfer is taking place. [233:5-10] Rejected. We can wordsmith this when it is consistent. Added UTI 091 about the contradiction in asynchronous i/o. [234:5+2] Instead did "file"->"unit" only. I don't like the sound of the suggested second statement. [234:9-10] Done. [234:11] Instead, "On output, if an internal file has been specified,"-> "For output to an internal file,". [234:27] No edit needed (the answer is "Yes."). [235:9-10] Done. [235:20] Instead, reworded to simplify as well as be more accurate. [235:34] Done with more substantial rewording. [236:2-5] Done. [236:11+ or 19+] Rejected - I think the current position is ok. [236:23+] Rejected - I disagree. The current position of this note covers both this case and [236:11+]. [238:10,25] Done. [241:9,13+1-3] Rejected. POS= is specified in the POS= subclause. REC= is specified in the REC= subclause. [241:13+13] Done. I added ",PRIVATE" to the PROCEDURE statement. [242:Note 9.53] Ditto. [244:2-4] Rejected. We don't hyphenate data transfer. [244:5-6] Done plus more rewording because the paragraph was even more deficient than Van noticed. Added UTI 092 about FLUSH needing to do a wait operation. [244:28-29] Done. [244:31-245:9] Also incorporated the opening paragraph of 9.6 into "Wait operation". Also made [244:32] a definition of "wait operation". [245:17-20] Did the first half, not the second. [246:9.7.3] No, it is not ok - it is prohibited by [245:17-18]. [247:24] Rejected - text is correct as it stands, edit would break it. [247:26] Rejected - current text is clear. [247:27+] Done. [249:24+] Rejected - this needs more careful review than I have time for at the moment. At least some of it seems to be unnecessary. [249:38-39] Done. [249:41-250:1] Done. [250:5-6] Did more substantial rewording instead (edit was broken). [250:26-27] Done. [250:29-31] Also joined the last two sentences of this paragraph by ";". [251:5-6] Done. [251:10] Done. [251:17+] No edit. Answers are "yes" and "otherwise, it becomes undefined". [251:21+] No edit. Answers are "yes" and "otherwise, it is assigned the value false". [251:24-26] Done, but also deleted an unnecessary "if" and "position of the file is indeterminate" -> "position is indeterminate". [252:15] Done. [252:27+] Question probably moot by co-array i/o changes. [253:4-7] Done. [253:15,20] Done. [253:23-26] Done. [253:40] Done. [254:16-17,22,26] Done. [254:29-31] I would have done this but ... the first two sentences are already handled by the opening paragraph of 9.9 File inquiry. And NONE of them have any restrictions. Therefore I have moved the remaining two sentences up to 9.9 File inquiry and deleted 9.9.2 Restrictions on inquiry specifiers. [254:35-36] Done. [255:7-9] Rejected. This seems ok as is (I don't like the suggested moving of the condition to the front, since it is an exceptional case). [255:16-17] Rejected. This paragraph is linking the timing to the execution of the statement. Deleting the final sentence would leave the paragraph misleading. I agree that the paragraph is not very informative as is... but I think this is not the right fix. [255:36-37] Done. [256:13-14] Done. [256:26] Done. [256:34-35] Done. [256:41] Done. - 06-203 [259:5,7] Done. [264:19-20] Rejected. Someone starting to read about data edit descriptors is entitled to know that file positioning can occur, not just editing. [264:37] Done. [266:19-267:1] Instead, moved it to a separate paragraph at [267:4+], and did not delete the clause about exponents. [267:28] Yes, it's an optional plus sign that has to appear. [267:31-33] Answers: No. No. This is all specified, and deliberately so. [267:35] Yes, it's an optional plus. [268:2] Done. [268:17-20] Converted to ISO-conformant list and table (incorporating line 21 into the table). [268:19] Done. [269:8-14] Converted to ISO-conformant list and table (incorporating line 15 into the table). [269:10] Done. [270:3-8] Converted to ISO-conformant list and table (incorporating line 9 into the table). [270:5] Done. [270:22,24] Done, except I deleted "exact" instead of replacing it. [271:24-27] Deleted the first paragraph. [273:4-8] Done, except for the deletion of the sentence beginning "When". [273:14] Rejected. This would be an INCOMPATIBLE TECHNICAL CHANGE. [274:6] Rejected. This would be an INCOMPATIBLE TECHNICAL CHANGE. [277:8-12] Rejected. This does not seem to be an improvement. [277:14,18] Rejected. Text seems ok as is (more drastic wordsmithing might be in order?). [277:20] Ditto. [277:22] Ditto. [277:35] Done. [278:2] Done. [278:31-37] "contiguous blanks" = blanks not separated by anything. [279:21-22] Answer: Yes, and yes. Substantially reworded paragraph. [280:15] Done. This is very poorly worded; in fact, deleting the sentence is probably better. [280:27] Changed "assignment" to "transference". [280:29] "is defined as though" -> "becomes defined as if". [281:6-8] "except for" -> "except as specified for", twice. [283:0+1] Done. [283:6] Contiguous means the same as it did before. [283:14] Done. [284:11+] I don't see what the problem is here. [284:12] Actually, they both seem to be about both input values and list items. I don't understand why these are separate subclauses. Maybe more reorganisation would be useful. [284:16] Done. [284:22-31+4] Done. [284:33] "assignment" -> "transference". [284:36-38] Done. [285:1+] Done. [285:16] Done. [285:29-30] Done. [285:34] Done. [287:11-288:5] Did not replace the subclause title. Also deleted [288:35]. [288:7] Done. - 06-204 [289:8] Done. [289:21] Instead, deleted this constraint (see editorial changes). [290:3] Instead, appended "by use association" to the sentence. [290:5] Instead, "a"->"by". [290:22] Instead, deleted this constraint (see editorial changes). [290:24-25] Reworded. [294:1] Done. [294:12] Instead, deleted this constraint (see editorial changes). [294:13] Did not insert "an", deleted later (obs) "a". - 06-206 [05-245r1] Done. [42:4] Done. [65:27] Already done. The answer to the question is "no". [65:30] Done. - 06-229 [342:8-9] Instead, made the sentence correct. I'll delete it if people really object to this, but I don't see any problem making correct (and informative) statements which incidentally make things explicitly processor-dependent rather than just not standardised. [360:22-30] Done. [361:7] Done. [383:4] Done differently by another paper. [06-166r2] Done. [418:32] Done. - 06-282 [222:4] Done by another paper. [245:25] Fixed by removing the BNF restriction. Similarly at [223:24], [225:21], [244:18], [247:12] and [249:17]. [245:26] Fixed by removing the BNF restriction and by changing the text to require a in a . Similarly for , , , . For INQUIRE, just deleted the BNF limitations on C949 and C950. For C951, deleted the BNF limitation and added text. - 06-211r1 General comment 1: Most (all?) of the "make it subsidiary" suggestions have been rejected. There seems to have been a misunderstanding about the meaning of subsidiarity: it means that the subsidiary items are a subset of the top-level items (or the qualifier relationship). That is, a qualified topic "qualifier topic" can be indexed as "qualifier topic" and/or as "topic!qualifier". Thus "argument association" is also indexed as "association!argument". Virtually all of the subsidiarity suggestions are exactly the opposite, they are indexing topics under qualifiers. We don't do that. These are noted as "REJECTED (Ns)" (Ns = Not subsidiary). Very occasionally we index "X of Y" as "X!Y", but I think that's wrong. E.g. "type of (a) primary" is indexed as "type!primary", but it should probably be "primary, type of" instead. I might fix these... some other time. General comment 2: Various comments have been rejected because they attempted to do something to a technical term (change it, delete it, merge it with another). Altering a technical term is not an indexing operation, it is an operation on all the uses of it in the text. All technical terms must be indexed "as is" (except for singular/plural and capitalisation). If it's not suitable for the index, well maybe it wasn't suitable as a technical term but that is a different question. Formatting issue - Page 657 is only one column and runs past the bottom of the page: Done. Combine under the category of "abstract", "abstract interface", "abstract interface block", and "abstract type": REJECTED (Ns). ...but I notice that abstract interface is not being indexed under "interface!...", unlike generic interface et al. Fixed. ...and I notice that abstract type is not being indexed under "type!...", unline base type et al. Fixed. ...and interface block is not properly indexed. Fixed. Make "argument association" subsidiary to "argument":REJECTED (Ns). Combine "argument keywords" into "argument keyword": Done. , and make it subsidiary to "argument": REJECTED (Ns). Make "array constructor", "array intrinsic assignment statement", "array pointer" and "array section" subsidiary to "array":REJECTED (Ns). Combine "array elements" into"array element":Done. and make it subsidiary to "array":REJECTED (Ns). Make "array element order" subsidiary to "array!element":REJECTED (Ns). Make "ASCII character set", "ASCII character type" and "ASCII collating sequence" subsidiary to "ASCII": REJECTED (Ns). Also indexed many uses in c07,c09,c10 as ASCII character type, and in c13:NEWLINE Also indexed ASCII collating sequence in c13:ACHAR,CHAR,IACHAR,ICHAR,LGE, LGT,LLE,LLT,NEWLINE. Changed ASCII to ASCII character type in c13:SELECTED_CHAR_KIND, thus removing the unnecessary bare "ASCII" entry. Make "assignment statement" subsidiary to "assignment":REJECTED (Ns). Combine "associate names" into "associate name": Done. Make "pointer association status" subsidiary to "association":REJECTED (Ns). ...fixed 1-element "association status!pointer" to be "association status, pointer" instead. Combine "attributes" into "attribute":Done. Make "attribute specification statements" subsidiary to "attribute": REJECTED(Ns). Index the KIND attribute: REJECTED - there is no such attribute. Combine "belongs" into "belong": Done. Do we need both "branch target statement" and "Branching", since they're both on the same page?: Yes, both are technical terms. Replace both by "branching": No, only "branching". Make "character context", "character intrinsic assignment statement", character intrinsic operation", "character intrinsic operator", character length parameter", "character literal constant", "character relational intrinsic operation", "character sequence type", character set", "character storage unit", character string", "character string edit descriptor" and "character type" subsidiary to "character":REJECTED (Ns). Make "common association" (if it continues to exist as a term), "common block" and "common block storage sequence" subsidiary to "common":REJECTED (Ns). ...but I did index "common association" as "association!common". Combine "components" into"component": Done. Make "component" and "component keyword" subsidiary to "component": REJECTED(Ns). Combine "Component order" into "component order":Done. and it them subsidiary to "component": REJECTED (Ns). Delete "connected files" (since "connected" is indexed on the same page): Done. Make "constant subobject" subsidiary to "constant": REJECTED (Ns). Combine "Construct association" into "construct association":Done. Make it and "construct entity" subsidiary to "construct": REJECTED (Ns). Combine "control edit descriptors" into "control edit descriptor": Done. Combine "data edit descriptors" into "data edit descriptor":Done. Make it and "data entity", "data object", "data object reference", "data pointer", "data transfer" and "data type" subsidiary to "data":REJECTED(Ns). Combine "data transfer input statements", "data transfer output statements" and "data transfer statements" into "data transfer input/output statement" and make it subsidiary to "data!transfer": REJECTED. (the first two are defined terms, not just index entries.) ...I agree something should probably be done here, but not this. Combine "declarations" into "declaration":Done. Combine "default-initialized" into "default initialization": REJECTED. This is a technical term. Make "default character", "default initialization", "default integer", "default logical" and "default real" subsidiary to "default": REJECTED (Ns). Make "defined assignment", "defined binary operation", defined elemental assignment statement", "defined elemental operation" and "defined operation" subsidiary to "defined":REJECTED (Ns). Make "defined assigned statement" subsidiary to "defined!assignment": REJECTED (Ns). Delete "defined unary operation": REJECTED, this is a technical term. Decapitalize "Delimiters":Done. Combine "derived types" into "derived type": Done. ...also changed "type!derived types" -> "type!derived", and indexed it properly (same range as "derived type"). Make "derived type determination" subsidiary to "derived type":REJECTED(Ns). Make "direct access input/output statement" subsidiary to "direct access": REJECTED (Ns). Combine "dummy arguments" into "dummy argument": Done. Make it and "dummy array", "dummy data object" and "dummy procedure" subsidiary to "dummy":REJECTED (Ns). ...dummy array and dummy data object need to be more widely indexed, but I have not done that (yet). dummy procedure probably ought to be properly indexed too. Combine "edit descriptors" into "edit descriptor": Done? Refer "edit descriptor" to "format descriptor": Done. Change "element array assignment (FORALL)" to "elemental array assignment (FORALL)":Done. I don't much like the name though. Make it and "elemental intrinsic function", "elemental operation" and "elemental procedure" subsidiary to "elemental": REJECTED (Ns). Combine "executable constructs" into "executable construct":Done. Make it and "executable statement" subsidiary to "executable":REJECTED (Ns). ...added UTI 095 about the incorrect definition of executable statement. indexed "statements!executable". Combine "expressions" into "expression": Done. Make "extension operations", "extension operator" and "extension type" subsidiary to "extension": REJECTED (Ns). Make "field width" subsidiary to "field": REJECTED (Ns). Combine "files" into "file":"files" is not indexed. You mean to move the "files" subitems "connected" "external" "internal" "preconnected" to be under "file" instead: Done. Make "file access", "file connection", "file inquiry", "file position" and "file storage unit" subsidiary to "file":REJECTED (Ns). Make "file connection statements" subsidiary to "file connection": REJECTED (Ns). Make "file inquiry statement" subsidiary to "file inquiry":REJECTED (Ns). ...instead, changed "file inquiry" indexing to "file inquiry statement", and added "statements!file inquiry". Make "file positioning statements" subsidiary to "file position": REJECTED (Ns). Combine "final subroutines" into "final subroutine":Done. Combine "finalizable", "finalizatioion" and "finalized": REJECTED - these are separate technical terms (except for finalization). ...they do appear to need better indexing though. Replace "format descriptors" by "format descriptor": Done. Make "formatted data transfer", "formatted input/output statement" and "formatted record" subsidiary to "formatted":REJECTED (Ns). Make "function reference", "function result" and "function statement" subsidiary to "function":REJECTED(Ns). Combine "Generic names" into "generic name":Done. Replace "generic procedure references" by "generic procedure reference":Done. Make them and "generic identifier", "generic interface", "generic interface block" and "generic procedure references" subsidiary to "generic": REJECTED (Ns). Combine "global entities" into"global entity":Done. Make it and "global identifier" subsidiary to "global": REJECTED (Ns). Replace "Graphic characters" by "graphic character": REJECTED - the former does not appear in the index. Make "host association" and "host scoping unit" subsidiary to "host": REJECTED (Ns). ...maybe "scoping unit!host" should appear in the index? (Not done). Delete "inheritance associated" index entry, and add its reference as part of "inheritance association.": REJECTED - technical term. Make "initialization expression" subsidiary to "initialization": REJECTED (Ns, plus it's a technical term). Replace "Input statements" by "input statement":Done. Make "input/output list" and "input/output statement" subsidiary to "input/output": REJECTED (Ns). ...doubtless input/output list should be more widely indexed, and the existing entry should be a definition. Make "inquiry function" and "inquiry, type parameter" subsidiary to "inquiry": REJECTED (Ns) for "inquiry function", and there is no point in making a 1-element subsidiary list for "inquiry, type parameter". Make "instance of a subprogram" subsidiary to "instance": REJECTED. Instead, I changed the "instance of a subprogram" indexing in Annex A into an indexing of "instance". Make "integer constant", "integer editing", "integer model" and "integer type" subsidiary to "integer":REJECTED (Ns). Make "interface body", "interface block" and "interface of a procedure" subsidiary to "interface":REJECTED (Ns). Combine "internal files" into "internal file": Done, and made the c09 one into a definition (that is the real definition, not the glossary). ...this should probably be more widely indexed throughout c09. Combine "intrinsic operations" into "intrinsic operation":Done. ...deleted "intrinsic operations!logical" (we don't do any of the other types like this), and de-indexed "logical intrinsic operations" from c04 (again, because we don't do the other types like this). Combine "intrinsic procedures" into "intrinsic procedure":Done, and fixed the indexing of these as well (should have been the same as that of procedure!intrinsic, but had a typo and the opening was misplaced). Combine "intrinsic types" into "intrinsic type": Done. Make them and "intrinsic assignment statement", "intrinsic binary operation", "intrinsic module" and "intrinsic unary operation" subsidiary to "intrinsic": REJECTED (Ns). Index "intrinsic function" and "intrinsic subroutine":REJECTED - where? Anyway, "intrinsic procedure" would seem to be adequate. Make "ISO 10646 character set" and "ISO 10646 character type" subsidiary to "ISO 10646":REJECTED (Ns). ...indexed many uses in c07,c09,c10 as ISO 10646 character type, and in c13:NEWLINE ...changed c13:SELECTED_CHAR_KIND to index ISO 10646 character type. Make "length of a character string" and "length type parameter" subsidiary to "length": REJECTED (Ns). Replace "letters" by "letter":Done. Combine "Lexical tokens" into "lexical token": Done. Combine "local identifiers" into "local identifier": Done. Make it, "local entity" and "local variable" subsidiary to "local": REJECTED (Ns). Combine "logical intrinsic operations" into "logical intrinsic operation": Done. Make it and "logical intrinsic assignment statement", logical intrinsic operator" and "logical type" subsidiary to "logical":REJECTED (Ns). Combine "masked array assignment" and "masked array assignment (WHERE)": Done. Make "module procedure", "module reference" and "module subprogram" subsidiary to "module":REJECTED (Ns). Make "named common block", "named constant" and "named file" subsidiary to "named": REJECTED (Ns). Combine "Nonexecutable statements" into "nonexecutable statement":Done. Combine "numeric intrinsic operations" into "numeric intrinsic operation": Done. Combine "numeric types" into "numeric type":Done. Make them and "numeric conversion", "numeric intrinsic assignment statement", "numeric intrinsic operator", "numeric relational intrinsic operation" and "numeric sequence type" subsidiary to "numeric": REJECTED (Ns). Combine "obsolescent features" into "obsolescent feature": Done. Combine "operands" into "operand": Done. Combine "operations" into "operation": Done. ...also, indexed operation!intrinsic in 7.1.2 and operation!defined in 7.1.3. Also indexed operation!extension. Combine "operators" into "operator": Done. Make "operator precedence" subsidiary to "operator": REJECTED (Ns). Replace "Output statements" by "output statement":Done. Combine "PARAMETER" into "PARAMETER attribute": REJECTED. The indexing of PARAMETER on page 20 does not seem to serve any useful purpose, and is not done for BIND (used on the same page) so I've deleted it. Make "parent component", "parent data transfer statement" and "parent type" subsidiary to "parent": REJECTED (Ns). Combine "pointer associated" into "pointer association". Make it and "pointer assignment" subsidiary to "pointer": REJECTED (Ns). Make "pointer assignment statement" subsidiary to "pointer assignment": REJECTED (Ns). But I did index it as "statements!pointer assignment". Make "pointer association status" subsidiary to "pointer association": REJECTED (Ns). Combine "Preconnection" into "preconnected":REJECTED - not without rewriting the text that uses it. Make "preconnected files" subsidiary to "preconnected": REJECTED (Ns). Combine "procedure references" into "procedure reference": Done. Make it and "procedure designator", "procedure interface" and "procedure pointer" subsidiary to "procedure": REJECTED (Ns). Make "real model", "real part" and "real type" subsidiary to "real": REJECTED (Ns). Replace "record lengths" by "record length":Done. Make it, "record file" and "record number" subsidiary to "record": REJECTED (Ns). Combine "relational intrinsic operations" into "relational intrinsic operation":Done. Make it and "relational intrinsic operator" subsidiary to "relational": REJECTED (Ns). Combine "representation methods" into "representation method":Done. Make "sequence association", "sequence structure" and "sequence type" subsidiary to "sequence": REJECTED (Ns). Make "sequential access input/output statement" subsidiary to "sequential access": REJECTED (Ns). Make "shape conformance" subsidiary to "shape": REJECTED (Ns). Make "size of a common block" and "size of a storage sequence" subsidiary to "size":REJECTED (Ns). Remove "specific interface block":REJECTED. This is a technical term, used in several places in the standard. Replace "Specific names" by "specific name":Done. Combine "specifications" into "specification":Done. Make "specification expression", "specification function" and "specification inquiry" subsidiary to "specification": REJECTED (Ns). Combine "Statement functions" into "statement function": REJECTED. The indexing of "Statement functions" serves little purpose. Instead, I have deleted both it and the indexing of "CHARACTER declaration" (the latter also serves little purpose). ...if people think that indexing this use of statement functions or character* declarations is useful, I suggest we should index the rest of the Annex B items as well, not just these two. Replace "statements" by "statement": REJECTED for now. Some of these are pretty weird Make "statement entity", "statement function", "statement label" and "statement order" subsidiary to "statement": REJECTED (Ns). Index "statement!ASSOCIATE":REJECTED - it already is. "statement!CLASS",:REJECTED - "CLASS IS" is already inxeded. "statement!SELECT TYPE",:REJECTED - it already is. "statement!TYPE":REJECTED - it already is. and "statement!TYPE IS".:REJECTED - it already is. Combine "storage associated" and "Storage association into "storage association":REJECTED - these are two separate technical terms. I did combine "Storage association" and "storage association" though. Make them, "storage sequence" and "storage" unit subsidiary to "storage": REJECTED (Ns). Make "structure component" and "structure constructor" subsidiary to "structure": REJECTED (Ns). Combine "subobjects" into "subobject":Done. Make "subroutine reference" and "subroutine subprogram" subsidiary to "subroutine": REJECTED (Ns). Make "subscript triplet" subsidiary to "subscript": REJECTED (Ns). Combine "transformational functions" into "transformational function":Done. Combine "type declaration statements" into "type declaration statement": Done, and fixed the indexing to exclude the attributes. Make it, "type compatible", "type conformance", "type equality", "type incompatible", "type parameter" and "type specifier" subsidiary to "type": REJECTED (Ns). Combine "Type parameter order" into "type parameter order":Done. Make it, "type parameter inquiry", and "type parameter keyword" subsidiary to "type parameter": REJECTED (Ns). Combine "ultimate components" into "ultimate component":Done. Make "unformatted input/output statement" subsidiary to "unformatted data transfer": REJECTED (Ns). Combine "use associated" and "Use association" into "use association": REJECTED:separate technical terms. I did combine "Use ..." though. Combine "variables" into "variable":Done. 274r2: [65:27] Note to editor: Should R449 and C462 from page 65 be moved to page 84:23+ where initialization is discussed (R505) and text 65:5-7 and 65:26-27 be moved to 85:15+ ? ...Please bring this up again later. Editorial suggestion: Check all cases of "considered to be" and "said to be" for deletion or rewording. - [23:15] "it said to become <>" -> "it becomes <>", [23:17] "it is said to be <>" -> "it is <>", [23:17-20] "Similarly ... <>." deleted. This is false; we don't use "definition" to talk about pointer association status, and in particular we do NOT have a pointer association status of "defined". [44:28] "is said to be type compatible" -> "is type compatible". [73:12] "are said to be <>" -> "are <>". [75:6] "are said to correspond" -> "correspond". - c04: "integer ... zero value, which is considered to be neither negative not positive". ok [128:14] "to become defined as disassociated" -> "to become disassociated". [209:3] "are said to <>" -> "<>". [215:31] "are said to exist" -> "<>" (This is definition-like.) [227:17] "said to be asynchronous" -> "<>", [227:19] "said to be synchronous" -> "<>"; both of these are definitions. For i/o, synchronous and asynchronous do not have their natural meaning but these ones. Went through c09 indexing asynchronous and synchronous. - [291:12] "11.2.1 The USE statement and use association", "are said to be <>" -> "are <>". - c15: "sequence derived types are considered to be the same type" -> "different derived type definitions describe the same sequence type". [476:27-28] "Fortran entity is said to be interoperable with the C entity" -> "Fortran entity <> with the C entity". NOTE: We often say "X is interoperable with Y" to mean "X interoperates with Y". To my mind "interoperates" is better, having "interoperable" mean specifically the capability of interoperation and "interoperate" mean specifically an actual interoperation. HOWEVER, I have not been through and changed these to be consistent. Yet. [511:18] "are said to be conformable" -> "are conformable". \stdref{175:19-21}[The paragraph contributes nothing that the syntax rules don't already specify. Editor: Deleted it, deferred consideration of adding something in Clause 2 to the next meeting.] - Blank lines between syntax rules (meeting straw vote). ...deferred until a later time. 4. Editorial changes - Introduced new subclause "2.2.1 Program units and scoping units" for the definitions of program units and scoping units. Changed references from 2.2 to 2.2.1 at [2:11], [487:6], [514:32,35], [518:31], [519:15], [520:20]. - Modified UTI 16 to reflect meeting discussion. - Deleted UTI 18 following meeting discussion. - Added 2.3.1 Statement classification for the opening material in 2.3. - Deleted duplicative "When ... executed." [325:32]. - Moved "Execution ... invoked." from [325:33-34] to [329:30+]. - Indexed CHARACTER_STORAGE_SIZE, COMPILER_OPTIONS, COMPILER_VERSION, FILE_STORAGE_SIZE, IMAGE_TEAM, IOSTAT_END, IOSTAT_EOR, IOSTAT_INQUIRE_INTERNAL_UNIT, NUMERIC_STORAGE_SIZE. changed ERROR_UNIT, INPUT_UNIT, OUTPUT_UNIT indexing to indicate where they are defined. - Changed "this standard" to "this part of ..." throughout c02. - Make UTI numbers 3-digit throughout. This improves their indexing. - [xv] Added item for Bessel, Gamma, Erf and Norm2. - [12:5] "A subprogram" -> "A <>" (this is the definition; indexed as such so the glossary entry is not the only index ref). - [17:5+2] "The image control statements" -> "Image control statements". - [21:20-21] Reworded to avoid using "may" for capability. "any image" -> "another image"; the previous version didn't really convey the remote access idea very well. Hmm, ought this not be a note? It's not saying anything normative. - [22:17] "this standard" -> "this document", and "definitions of terms" -> "terms and definitions". (Brings the wording closer to that required by ISO.) - [23:14] "and" -> ", enumerations, and". (we use "definition" for enumerations too.) - [24:14] "7.1.3" -> "\ref{D4:Type-bound procedures}, \ref{D12:Generic interfaces}" (this ref was supposed to be for *defining* additional operators, which has nothing to do with 7.1.3). - [25:1] Changed clause 3 title to be more accurate. - [25:2-3] Deleted unnecessary witter. - [36:21] put \si{} around basic-token-sequence. - [42:2] Appended "All type parameters are of type integer.". - [43:2] After selector insert ", and for a named constant of type character that assumes its length from the \si{initialization-expr}." - [48:4] Fixed cross-ref that went wrong. - [50:22] Fixed misstatement about character length and wordsmithed it. - [50:31-32] Reworded incorrect "or the ... type" -> "and its corresponding representation method is the ... type", twice. - [61:17,62:1-3] Integrated into the only place it is used. - [62:24+] Added UTI 094 about inconsistent constraints. - [65:15] "an" -> "a colon or" (bad constraint). - [77:11+2] "may" -> "can". - [84:34-] Added new subclause heading "5.2.2 Automatic data objects", and new constraint "An automatic object shall not be a local variable of a main program, module, or submodule.". - [87:19] Deleted "not ... is:". - [87:22] "nonpointer array" -> "nonpointer whole array" - [88:9+] Appended "(f) It is not the real or imaginary part (\ref{D6:Complex parts}) of an array of type complex." - [90:9-12] Paragraph was incorrect ("the procedure" magically appeared from nowhere without explanation) and did not have the BLOCK construct integrated into it. Replaced with "An explicit-shape array that is a local variable of a subprogram or BLOCK construct may have bounds that are not initialization expressions. The bounds, and hence shape, are determined at entry to a procedure defined by the subprogram, or on execution of the BLOCK statement, by evaluating the bounds expressions. The bounds of such an array are unaffected by the redefinition or undefinition of any variable during execution of the procedure or BLOCK construct." - [91:8] Inserted "allocated" before "allocatable". - [91:9] Inserted "associated" before "array pointer". - [91:19] Deleted "-list" and added "..." after the first "]". This is because otherwise [90:2] would claim that an assumed-size array is an explicit-shape array. - [92:1] "an " -> "a list of s" (fallout from 91:19 change). - [103:12] "" -> "", to improve the typesetting (it is never referred to, so what we call it is relatively unimportant). Actually, why do we claim that these things are co-ARRAYs anyway? They are just "co" (directly accessible from other processes), they are not actually array-like (there are N copies of them, just like every other object), well, the only thing that is array-like is the similarity of the syntax for specifying the image for the remote access. - [112:2] Improved cross-ref "4.5.2" (Derived-type definition) -> 4.5.2.3 (Sequence type). - [130:6-7] "If a specification expression in a scoping unit references a function whose result is either allocatable or a structure with a subobject that is allocatable," -> "If a function whose result is either allocatable or a structure with an allocatable object is referenced in the specification part of a scoping unit or BLOCK construct," {Integration of BLOCK.} - [130:9] "first executable statement in" -> "executable constructs of". {Missed edit from Corrigendum 1.} - [130:9] Appended "or block". {Integration of BLOCK.} - [143:17+] (before the note) inserted "If a specification expression in a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the specification expression." {Missing edit from Corrigendum 1, modified for submodule integration.} - [144:35+] (before the note) inserted similar text for initialization exprs. {Missing edit from Corrigendum 1, modified for submodule integration.} - [154:12+1] Shortened table title to improve typesetting. - [158:1] Deleted unnecessary "and". - [161:0+7-8] "copies it to"->"uses it for" and "remaining bits"->"rest". {Avoids treating everything as if it were just a string of bits.} - [161:4-5] Swapped the last two clauses to improve readability, and inserted a new sentence for unallocated co-array components giving them the semantics I expect were intended. - [161:16+5-6] Removed spaces around "%" to improve readability. - [162:25+] Introduced new subclause heading "7.4.2.1 General" for the opening witter. - [162:31+] Introduced new subclause heading "7.4.2.2 Syntax" for the syntax. (It's not entirely, but is mostly, about the syntax.) - [180:2] Made "ASSOCIATE construct" into a definition. - [181:6+] Inserted new constraint " shall not be a reference to a function that has a pointer result". {Disambiguate syntax.} - [182:2] Made "SELECT TYPE construct" into a definition. - [182:3] "expression" -> "expression or variable". - [185:3] Make "DO construct" into a definition. - [186:8,21] "action-stmt" -> "", twice. - [187:19-20] Deleted sentence defining iteration count for DO CONCURRENT, because it is never used. - [187:28-30] Split into two, improved typesetting, constraintified, moved to 189:8+ (with the other DO CONCURRENT constraints). - [191:28] Appended forward ref to {D16:Statement and construct entities}. - [193:9] After "", inserted ", , , ,". {As branch target statements.} - [197:2] Unemboldened "unordered" - this is being used in a normal sense, and is only used within this subclause so doesn't justify becoming a special technical term. - [197:3+4] Deleted "or user-defined ordering", as it does not add anything, and makes the sentence ungrammatical. If people object, I can delete the whole back end of the sentence instead. - [197:9] Inserted "pointer" before "association" (ambiguous otherwise). - [222:5] "invoke" -> "execute". - [224:17-] Inserted subclause heading "9.5.1 General". - [224:24-] Inserted subclause heading "9.5.1.1 Syntax". - [226:25] "FMT= specifier" -> "Format specification". {PRINT, and READ without an i/o-control-list, don't have an FMT= specifier.} - [226:26] "FMT= specifier" -> "\si{format} specifier". {PRINT, and READ without an i/o-control-list, don't have an FMT= specifier.} - [227:10] After "If YES is specified" inserted "for a nonchild input/output statement". {Avoid lying.} - [231:19+3] "may have to be" -> "might have to be". - [236:17] "input item" -> "effective item", "descriptor" -> "descriptors". - [245:10+] Inserted subclause heading "9.7.1 Syntax". - [248:1] Changed subclause title to "9.9 File inquiry statement", to better match the rest of c09. - [248:1+]] Inserted subclause heading "9.9.1 Forms of the INQUIRE statement". - [256:21] "input list item" -> "effective list item", [256:22] "descriptor" -> "descriptors", "requires" -> "require". - [267:12-14,17-19] Converted to bullet lists. - [278:15+] Inserted subclause heading "10.10.1 General". {An alternative would be to delete the waffle at [278:16-18].} - [278:18+] Inserted subclause heading "10.10.2 Values and value separators". - [283:1+] Inserted subclause heading "10.11.1 General". {An alternative would be to delete the waffle at [283:2-3].} - [283:3+] Inserted subclause heading "10.11.2 Name-value subsequences". - [283:21] Indexed "&" as a normal word, not as a language keyword. - [289:1-5] Delete unnecessary redundant witter. - [290:2+] Added new subclause heading "11.2.1 General". - [292:30] "in subclause 16.3.4" -> "in 16.3.4". - [292:30] Inserted "and \ref{D12:Generic interfaces}". - [297:17] Deleted unnecessary waffle. - [297:25-27] Deleted unnecessary and duplicative waffle. - [298:18] Split "12.3 Characteristics of procedures" into "12.3 Characteristics" and "12.3.1 Characteristics of procedures", and fixed cross-references to point to the appropriate one. - [298:22+] Inserted subclause heading "12.3.1.1 General". - [299:11+] Inserted subclause heading "12.4.1 General". - [299:26] Deleted subclause heading "12.4.1.1 Explicit interface". - [300:18+] Inserted subclause heading "12.4.2.1 General". - [303:1-] Inserted subclause heading "12.4.2.2 Generic interfaces". - [307:10] Unjoined R1216 from R1215. - [308:15+...] "GAMMA"->"GFUN" twice. {To avoid possible confusion now we have an intrinsic of that name.} - [309:11+] Inserted subclause heading "12.5.1 Syntax". - [309:13] Fixed excessive space. - [309:14] ":" -> "as follows.". - [318:14,18,21] "the dummy argument" -> "a dummy procedure", thrice. - [318:18] Deleted "the name of". - [318:19] Deleted "it is", "the dummy argument" -> "it". - [323:4+] Inserted subclause heading "12.5.4.1 Establishment of procedure names". - [324:1,2] Deleted the second "if" on line 1, the only "if" on line 2. - [324:4+] Inserted "Otherwise, if the name is that of an intrinsic procedure and the reference is consistent with that intrinsic procedure, the reference is to that intrinsic procedure." {Missing edit from Corrigendum 1.} - [330:7] Replaced rhs with \si{mp-subprogram-stmt}, [330:11+] Inserted " <> " plus previous rhs, [330:11,12,16] "sep"->"mp", thrice. Plus corresponding changes in c02. {Syntax was just plain wrong: it didn't make the first thing a statement. Improved the naming at the same time.} - [332:8-9] "PURE is specified or ELEMENTAL is specified and IMPURE is not specified in the SUBROUTINE or FUNCTION statement" -> "the subprogram is a pure subprogram". - [357:20,21,22] Inserted "approximately" before pi etc. - [360:7] Inserted missing definite article before "result". - [363:17-26] Moved to alphabetical positioning. - [375:18-20,30-31] Rewrote Result Value paragraphs of DSHIFTL and DSHIFTR to hopefully make more sense (and typeset better). Moved the useless comments about ISHFTC equivalence into the examples paragraphs. - [380:34] Inserted "the result of" after "one,". - [382:5] After "following" inserted "code fragment". - [382:22] Replaced "model representation" with text from Corrigendum 1. - [382:22-23] Replaced the last three sentences with a single sentence. - [383:13] Fixed typesetting. - [384:16] Ditto. - [386:25] Deleted "(optional)" because DIM is not optional. - [390:10-11] Simplified example. - [392:20] Deleted "(optional)" because DIM is not optional. - [398:31,32] Inserted "approximately" twice. Not many computer arithmetics can exactly represent transcendental numbers. - [406:1] Shortened example to improve typesetting. - [422:6] Improved typesetting. - [422:15] Applied corrigendum 1. - [422:16+] Added UTI 092 because RRSPACING is contradictory. - [424:4] "SELECT"->"SELECTED". - [426:8] "model representation of X" -> words from corrigendum 1. - [426:8] "has value zero, the result has value zero" -> "has the value zero, the result has the same value as X". - [426:8+] Added UTI 093 because SET_EXPONENT is broken for INF and NaN. - [429:22] After "zero" inserted "and is not an IEEE infinity or NaN". - [429:23] "model representation of X" -> words from corrigendum 1. - [437:24] Inserted "intrinsic" before "modules". - [438:13,22] Shortened examples to improve typesetting. - [438:22+1] "VERSIONS"->"VERSION". - [439:4] "hyphen 1" changed to "minus 1". - [440:7,33] Ditto. - [476:26] "define" -> "defines". - [498:7] Delete "and". - [498:31] "also is accessed" -> "is also referenced". - [498:34] "descendant submodules" -> "descendants". - [503:7-21] Changed to a bullet list. - [505:26-27] "an ALLOCATE ... SYNC_TEAM statement" -> "a statement". - [505:29-30] "an ALLOCATE ... SYNC TEAM" -> "a". - [505:47] After "FORALL" inserted "or DO CONCURRENT". - [509:10] Deleted glossary definition of "action statement", since it happens only to be used in one place and its meaning is clear there. - [510:10] Deleted glossary definition of "character", because it was just plain wrong, as well as being useless. - [511:30] Was badly worded (a file does not "have" a unit). Fixed. - [515:20] Deleted glossary definition of "interface of a procedure", which is pointless. - Index: Merged bold and nonbold "ASSOCIATE construct". - Index: Merged bold and nonbold "SELECT TYPE construct". - Index: Indexed subclause "Resolving type-bound procedure references" as "type-bound procedure", "procedure reference!type-bound", and "procedure!type-bound". Also cross-indexed the definition of "type-bound procedure" as "procedure!type-bound". - Index: Indexed "CONTIGUOUS attribute" in D5:CONTIGUOUS statement, and "attribute!CONTIGUOUS" there and in D5:CONTIGUOUS attribute. - Index: Indexed "CONTIGUOUS statement" and "statements!CONTIGUOUS" at D5:CONTIGUOUS statement. - Index: Indexed "default initialization" to where it is defined, not just to the glossary. - Index: Indexed D4:Derived types and D4:Enumerations and enumerators as "specification". - Index: Indexed "TYPE statement" in the same place as "statement!TYPE". ===END===