J3/06-185 Date: 2006/07/18 To: J3 From: Malcolm Cohen Subject: Editor's report for J3/06-007 preparation. 1. Introduction. This document is the editor's report resulting from the incorporation of the combined edits from paper J3/06-014r1 into the standard, producing J3/06-007. I tried to make a comment for every change I made, but I might have missed some ... especially the ones which got made while reviewing the output. All Unresolved Technical Issues are listed in standing document 011. This does not include previously-mentioned editorial changes (many of these are listed in the 008). It does include processing of corrigendum 2 and further processing of the enhanced modules. 2. Generalities Co-arrays, Bits, Macros (excluding BLOCK), and BLOCK have all been conditionally inserted into the document; disabling these features is relatively easy. In this document, UTI = Unresolved Technical Issue. These are listed in another document, and indexed in J3/06-007 as ZZZUTIn where n is the number. Almost none of the new terms are indexed at all, let alone properly. If people wish to tell me which terms they think are important enough to index, I can make an initial indexing pass. 3. Trivialities - In the intro, "The concept of \si{variable} now includes references to pointer functions" changed to \textit{variable} because the hyperlink.f90 program expects page numbers to be arabic numerals, and this is on page xiii. I don't think this needs to be the syntax term anyway, it's just as valid talking about variables in general (nice to have it italicised though). - Changed "this standard" to "this part of ISO/IEC 1539" throughout c01. Did it with a macro to make it easier to change again should the ISO directives so require. Note: This points out the clumsiness of some of our wording, which could doubtless be simplified, deleted, or otherwise improved. (Going "this standard ... this standard ... this standard" is bad enough, and looks even worse now.) Note: Yes, I know we have clumsy wording to define "this standard" at the front (to be this part of ISO/IEC 1539), but that's just sloppy. - Changed a singular "standard conforming" to "standard-conforming" in the Introduction, once in c01, once in c04, thrice in c05, once in Annex A, thrice in Annex C. "Standard conforming" is always an adjective, never a noun, so should be hyphenated consistently (most of them were hyphenated). - The entire compatibility subclause is slightly problematic. This is nothing new: the Fortran 90 compatibility subclause in Fortran 2003 was also wrong, because it needed to repeat the Fortran 95 incompatibilities but did not. Much of this could be fixed by removing the older ones. Alternatively, rather than repeat the tiresome incompatibility paragraph, some wording like "additional incompatibilities" or something would be appropriate. 4. Incorporation of J3/06-014r1. - As promised, moved the edit from J3/06-174r3 at [13:17++] to 2.3.5 (within Execution concepts) which is where it seems to belong. - Inserted UTI 1 about the model being used for parallel programming. - The note the subgroup claimed was "useful cross-references" looks like unimportant waffle to me. Especially the first sentence, which tells the reader something he has known for the past 50 years. - Added UTI 2, about the lack of rigor in saying what is replicated and what is shared. - Note normative assertion requiring support for single-threaded programs. - Inserted UTI 3, about the definition of Normal termination. - Inserted UTI 4, about the reporting of signalling IEEE exceptions on termination. - Deleted unnecessary second forward reference for "signaling". - Added UTI 5, about the behaviour of STOP not preceded by SYNC_ALL. - Inserted UTI 6, about scheduling of termination after STOP. - Replaced the second paragraph of 2.4.1.1 with much simpler, and correct, wording. The new wording doesn't go into unnecessary redundant detail. - Inserted UTI 7, about the use of the undefined term "co-dimension". - Added page xiii item for complex part selectors. - Added a syntax rule limitation for the constraint about . - Added a syntax rule limitation for the constraint following the BNF for the END MACRO statement. - Replaced 256*130 with 33280 as the maximum number of chars in a macro- produced statement. - Changed "macro-optional-declaration-stmt" to "macro-optional-decl-stmt", so that it fits in the space we allow. - Deleted "KIND," in the opening paragraph of "Bits type" (all the other intrinsic types just talk about their kind type parameter, and this is defined generally in 4.2 so there is no need to repeat that here). - I would have made the reference to NUMERIC_STORAGE_SIZE say where it came from (it is not, in itself, intrinsic), however, it typesets badly anyway (being a great big long lump of a name). Since it means "the size of a numeric storage units expressed in bits" which is more concise than "NUMERIC_STORAGE_SIZE from the intrinsic module ISO_FORTRAN_ENV" I have changed it to the former. - The note "Even if a bits value is too large ..." really ought to be deleted. We don't say this for character strings and arrays, and bits are even more trivial in this regard. - In the edit for [51:20+], changed another "attribute" to "clause". - In the edit for [53:5+], changed "" to "", and changed the constraint C452b wording appropriately. - In the edit for [53:7+], changed "" to "variable", and "the variable" to "its designator". There seems to be some confusion here between syntax and semantics... I've decoupled the "variable is an initialization target" concept from the syntax constraints on its designator (viz that things have to be initialization expressions), going back and modifying C452b accordingly. - [59] Also did "" -> "the variable" twice. - is a real pig, crying out for absorption of the always- surrounding square brackets so we don't have to repeat them all over the shop. - Edit for [72:16+], moved constraint to follow the one for having the POINTER attribute, changed it to ref otherwise it doesn't see the . - Following the edit for [72:33], I added text to say that a PARAMETER could not be a co-array. But are co-arrays not always variables or components? So this is probably unnecessary, at least if there is correct wording elsewhere (ok, that is a pretty big if). - Inserted UTI 8, about how J3/06-174r3 edit for [73:1+] says to insert stuff where it does not belong. - Inserted UTI 9, about the utter nonsense of the note inserted by [73:1+]. - Changed "subcomponent" to "ultimate component" in one of the constraints inserted by [73:1+]. The term "subcomponent" doesn't apply to types, and ultimate components was, I think, what was meant anyway. - Inserted UTI 10, about the inconsistency of the SAVE special-casing for co-arrays. - Modified edit for [75:8] to be applicable to the TYPE type specifier generally, not just in type declaration statements. (The text it is modifying is now in c04, not c05.) - [73:1+] NOTE 5.2b, inserted it somewhere else. Maybe not in quite the right place, but better than in the middle of a list of unrelated constraints (said list having been dispersed anyway). Again, this is crying out for a CODIMENSION attribute subclause. Also, the Note says "The target of such a pointer component is always on the same image." but this is true of *ALL* pointers! This is almost entirely editorial, but definitely warrants fixing when the dust has settled. This sentence at least probably belongs under the POINTER attribute if there is no CODIMENSION attribute. - Inserted the edit for [74:20-] somewhere else. Reworded. I'm not sure I got the placement quite right, but I think it is close. (All this stuff probably needs reorganising though.) - [76:5+] Inserted after fifth paragraph, instead of in between <> and its concomitant <> definition. UTI 14 about placement; "bits compatible" has conspicuously nothing to do with "CLASS", the title of this subclause. (Yes, that's only editorial, but it's majorly enough editorial to *require* fixing.) UTI 15 about the lackingness of the definition. UTI 16 about the necessity of the term or otherwise. - [76:7-9] UTI 17 about broken generic resolution. UTI 18 about bit lengths and future extensions. UTI 19 about bit arguments and explicit interfaces. Note: The TKR definition is now harder to read than before, and it was not all that easy before. - [78:2-] Changed the semantics of the CONTIGUOUS attribute to limit it to those entities for which it may be specified (since subgroup didn't get back to me on my earlier comments about it). Probably needs wordsmithing, but the overly general "specifies that an entity is contiguous" is, I think, bad. - The edit for [78:2-] inserts a non-ISO-conformant nested list. Inserted UTI 11 about this (ok, so it's not technical, but it needs resolution). - [78:3-9] Used "it" for "the entity", twice. Should it say "has an " instead of "an appears"? The definition of <> should probably be elsewhere. Is there anywhere which gives the actual semantics of or is this it? Inserted UTI 12 since nothing says what l_i and u_i are - the sentence is meaningless gibberish. - [78:14] Added UTI 13 about the lack of correct semantics (and presence of incorrect ones) resulting from the misuse of and . - I wonder whether the changes of J3/05-210r2 of "associated actual argument" to "argument associated entity" are really all necessary now? And should it not be "argument-associated entity"? - Edit for [88:12-15] inserted "of" before "a containing" to eliminate the unlikely ambiguity of "X of Y or Z". (It doesn't make sense to read that wrongly, but eliminating the possibility seems good anyway.) - Edit for [89:15] before the replacement "data statement object", changed "a" to "the corresponding". Same edit, in the additional sentence, changed "" to "data statement object". Note: looks like this sentence could be wordsmithed a bit further. - [90:2-5] Did slightly differently. - [98:22] Did slightly differently. This list could maybe be reorganised. - [105:9+] Removed unnecessary parentheses around \si{section-subscript-list} in C613a. I don't like the wording of "This restriction is needed to avoid a disallowed pointer assignment for a component, such as" but don't have a ready substitute. UTI 20 about "Z[P] = Z" when Z has an allocatable component. Subgroup's suggested resolution has significant drawbacks. Didn't insert "J3 TECHNICAL NOTE (2)" from this edit as an UTI, since any resolution of UTI 20 seems highly likely to make this moot. - [110:2-] The requirement "An image selector shall specify an image whose index is in the range 1, ..., NUM_IMAGES()." is rather problematic on two counts: (1) NUM_IMAGES is not identified as the intrinsic function, (2) Images with indexes greater than the number of images do not exist, so ``"an image with index" > the number of images'' is an oxymoron. Changed to "An image selector shall specify an image index value that is not greater than the number of images." (It doesn't need to require 1+, since that is guaranteed by the previous sentence about each co-subscript being within the bounds.) Added UTI 21 about the lack of rigor specifying this mapping (J3/06-014r1 had this complaint under the THIS_IMAGE intrinsic, but the obvious place to define it is right here). - [110:15+] Put the ALLOCATE options into alphabetic order as well. - [111:36] Added UTI 22 about the problem of avoiding unexpected co-array allocatable components in the derived type. - [113:21+] Did it as per J3/06-014r1, but my comment stands about the excessive duplication of text vis-a-vis implicit synchronisation. - [116:19-] Did the alternative version of the last paragraph. - [119:2] Did as the paper said: I'll consider changing "character operator" to "character concatenation operator" or indeed simply "concatenation operator" later. - [121:7+] The changes to the intrinsic operator table resulted in defining the .AND. et al operations for integer-only operands. This goes beyond the passed specs and syntax (J3/05-274r3) from which I quote "The .and., .or., .xor., .eqv., and .neqv. operators are defined for one bits and one integer operand. The integer operand value is interpreted as a bits value of the same bit size and the operation is performed for the two bits values." Paper J3/05-175r2 did not make any change to the specs and syntax, therefore I assume that this change was by mistake (whether inadvertant or not). The changes I have done do not allow .and. et al for integer-only operands. - [121:25] Added here the new paragraph taken from the edit at [135:22-]. - [124:44+] Changed "BITS_KIND() and BITS_KIND()" to "kind type parameters of $x_1$ and $x_2$". ...because the intrinsic BITS_KIND is not necessarily available in the scoping unit (and it didn't say it was the intrinsic anyway). - [125:41] Inserted a new item instead, since it read kind of funny for a reference to be to two functions instead of just one of them "the bits kind inquiry function BITS_KIND,". - [126:3-4] from J3/06-140r1: Inserted a forward reference. - [126:27-29] converted replacement list to ISO conformance. - Split defined operations into their own subclause of 7.2 Interpretation of operations, "Interpretation of defined operations". - Simplified wording at [135:1-4,9-12]. - [135:22-] Did the alternative change. - NOTE TO THE EDITOR: The existing text is very sloppy about conversions, about half of the places rigorously saying "according to the rules of intrinsic assignment", the other half just hand-wavingly saying "converted". We should probably have a subclause "Conversions" which covers everything (not just intrinsic assignment!) and everything should reference that subclause. - [135:28+] Added .XOR. at the end instead. - [136:2-] Added a column for .XOR. to table 7.6 instead. - [136:2-] Fixed capitalisation of table 7.6a, and put it in the same order as the table of logical operators. NOTE: The fourth column of this table is a mere elaboration of column two. It probably needs revision to avoid wasting ink stating obvious conclusions. Added columns for .EQV. and .NEQV. to the bitwise values table. - [136:5+] Replaced "Logical" with "Logical, Bits" not "Logical or Bits" (it's not a disjunction). - Around there: fixed the last line of the table "defined-binary-op" -> "". - [138:12-13] from J3/05-278r2, deleted unnecessary "in an ". - [138:19+] added UTI 23 about co-indexed variables and reallocating asgn. - [138:21] added UTI 24 about co-arrays/co-indexed vars and polymorphic assignment. - [139:3-] from J3/05-198r1 with J3/05-278r2: (modified by J3/06-154r4:), this was too long and hard to understand, so I broke it into two items, first doing the (simple) kind type parameters, then doing the length type parameters. - All the edits to 7.4.1.2 interacted in really horrible (ok, interesting) ways. I think I got these all right... The numbered list in 7.4.1.2 is now big and complicated. I think it needs restructuring. - [139:15-19] Despite saying "all occurrences", this edit didn't mean it; it deliberately did not change the occurrences on line 15 & 17, nor the second occurrence on line 18. On line 19, changed the second "" to "it" instead. - [139:23] ", or if" -> ", or" (the "if" was factored out of the second case, so needs to be factored out here too). - Line 25, fixed incorrect pluralisation of "corresponding type parameter". - [141:14-] Made the list in the note a bullet list instead of an enumeration. - [143:14] This edit made the sentence ambiguous; fixed by inserting an "either" and deleting a comma. Also, removed the cross-reference after bits compatible since that was to the same place as type compatible (earlier in the sentence). NOTE: this use of bits compatible would clearly be covered by "type and kind compatible". - [143:25+] Changed BNF ref from R735 to R736 . - [143:31+] "allocate statement" -> "ALLOCATE statement". - [144:5] Result is not what the edit says due to previous editorial change. - [144:38+] I don't like the consecutive "Otherwise", but it's not obvious how to improve it. - [147:24] Should have been [147:23] and the third paragraph, not the fourth. Deleted mistaken "assigned". - [155] Fixed contradiction about "belongs" by changing "A statement belongs" to "Except for a CYCLE statement, a statement belongs". - [161:19] Said to propagate the CONTIGUOUS attribute into ASSOCIATE and SELECT TYPE. This is fundamentally incorrect - an associate-name is not a pointer nor is it a dummy argument. Therefore, I instead inserted "The associating entity is contiguous if and only if the selector is contiguous." - p164, introduced "General" subsection for 8.1.6 DO construct. - [164:3] This edit would have made the sentence unreadable and borderline ungrammatical. I thought about appending ", except that an EXIT statement is not permitted in a DO CONCURRENT construct" but since the sentence is content-free waffle anyway (STOP, GOTO and RETURN similarly "modify the execution of a loop") I deleted it instead. To the extent that it was informative, the second paragraph contains the same information better stated. - [164:8+] Changed "A <>" to "The DO CONCURRENT". This is just the name of a construct, not a defined term. Changed "with a \si{loop-control} of [,] CONCURRENT " to "whose DO statement contains the CONCURRENT keyword". - [166] Deleted [166:27] as it was a simple duplication of the first sentence of the DO construct itself. Added the second sentence [166:28-29] as a separate paragraph to the initial material. This makes 8.1.6.4 ISO-conformant. - [167:23+] Added UTI 25 about the definition of "iteration" almost certainly breaking the rest of the standard. - [167:29+] Changed "a construct that contains the DO CONCURRENT construct" to "an outer construct". - [167:34] "curtails that iteration" -> "completes execution of that iteration" because otherwise, that iteration never has its execution completed, and so the DO loop never terminates. This is still pretty horrible though. Further wordsmithing useful. - [168:16] This edit omitted as moot due to earlier editorial change. - [168:23+] I did this to 21+ instead. It's a close call. - [168:24-] I made all the non-note paragraphs of this edit into a bullet list, preceded by an introductory sentence which said that these restrictions applied to DO CONCURRENT loops. That seemed a lot easier than rewording them all to be correct (they all assumed that just because the title of the subclause was XYZ, they only applied in the context of XYZ). - [169:1--] "1..N" -> "1, ..., N". - [169:1-] (EXIT) Omitted the unnecessary BNF refs on the constraints. - [169:1-] After "in the " insert "of a BLOCK construct". - [169:1-] "<>" -> "CRITICAL construct" once "critical construct" -> "CRITICAL construct" throughout. - [170:25-26] Added UTI 26 about misplaced duplicative text. Added UTI 27 about ambiguities. Added UTI 28 about contradictions. Added UTI 29 about lack of specification. Inserted editor's suggested rewrite: subgroup didn't like it, but it is hopefully useful input. Added UTI 30 about image 1 being extra-special. Added UTI 31 about things like atexit. Added UTI 32 about warnings for STOP vs END PROGRAM. - [170:29+] Changed cross-ref to 9.4 for ERROR_UNIT of ISO_FORTRAN_ENV to be 13.8.2.2 (9.4 was "File connection", which does not seem very relevant here). Added UTI 33 about lack of specification for the process exit status for STOP without a code. - [170:29+] Inserted the "[not at 130:1-]" text after the list of image control statements. Made the image control statement list a bullet list, and ISO conformant. Decided on a format for segment denotation. Added UTI 34 about a confusing restriction in the segment restriction list. Changed "corresponding actual argument" to "argument associated entity". Made the FLUSH condition list a bullet list. In the first FLUSH condition, added k>=i (otherwise it was not clear as to whether k was required to be different from i). After "The STAT= and ERRMSG= specifiers" added "for image execution control statements". I don't see what "The processor might have special hardware or employ an optimized algorithm to make the SYNC\_ALL statement execute efficiently." explains. It just looks like an ad for Cray to me. Reordered notes 8.23 and 8.23a, since 8.23 (if one ignores the ad) is simply an example, whereas 8.23a tries to explain things. Removed the BNF restriction from the first occurrence of the constraint, and deleted all of its duplicates. Changed "of the type IMAGE_TEAM defined in" to "of type IMAGE_TEAM from" (other text would suggest "IMAGE_TEAM of", but that reads a bit funny). Inserted "the intrinsic function" before FORM_TEAM. Split the last sentence off of the huge team synchronisation paragraph. It is still too hard to understand, and cries out desperately for rewording. Added UTI 35 about an ambiguity in SYNC_TEAM, which seems to be completely redundant anyway. Reworded the opening sentence of the sync_team example. In C840, changed "shall not contain an (ref)" to "shall not be a co-indexed object" (no ref). Deleted unnecessary BNF limitation on C840. Added UTI 36 about C840 being unnecessary and ineffective. Changed "in the range 1, ..., NUM_IMAGES()" to "positive and not greater than the number of images" (this was simpler than trying to specify that we meant the value returned by a reference to the intrinsic function). Attempted to correct the wording of the "Execution of a SYNC_IMAGES" paragraph (it defined T in the plural and then used it singularly). It is still almost unreadable. The QUERY statement definition is unrefined gobbledygook. It grievously misuses the common technical term "blocking" to include one of the nonblocking cases. This (misguided) definition of <> applies to statement executions, but it gets used as if it applied to statement themselves. The paragraph about corresponding NOTIFYs and QUERYs was really horrible to try to understand. In fact I couldn't, since it was partially ambiguous (it didn't say when the equality had to be satisfied). I completely rewrote the blocking/correspond stuff; what the paper (and almost no computer practitioner) called "blocking" I termed "satisfied" ("successful" would be ok, though that word is overused elsewhere). Moved note 8.28 into the general part of image control, since it had little to do with NOTIFY and QUERY. I might not have found the optimal position. Using M and T for image names is cute, but not terribly understandable. Something wrong with P and Q? "discussed" -> "described". Why are we trying to expand the vocabulary? Added UTI 37 about an unnecessary paragraph. Made the examples into notes. Added UTI 38 about lack of STAT= not causing error termination. - [178:30-32] Inserted "equal to" before "one of the named constants", kept existing shorter text about the named constants (the new text just seems longer, and I didn't like the "(...)(...)" effect). - [179:33] Added UTI 39 about the direct contradiction made by this edit. - [181:33+] Also changed title of 9.4.5 from "The OPEN statement" to "OPEN statement", like almost all our other statement subclauses. - [183:32+] Specified what ERROR_UNIT etc were and where they came from, and inserted "equal to" since a value cannot "be" a named constant, viz "shall not be -1, ERROR_UNIT, INPUT_UNIT, OUTPUT_UNIT, any value used ..." -> "shall not be equal to -1, any of the named constants ERROR_UNIT, INPUT_UNIT, or OUTPUT_UNIT from the ISO_FORTRAN_ENV intrinsic module (ref), any value used ..." - [185:4+] Also changed title "The CLOSE statement" -> "CLOSE statement". Added UTI 40 about the lack of ability to inquire the connect team. Added UTI 41 about unnecessary specs and contradictions. Made a bullet list instead of a numbered list; rewrote the list. Added UTI 42 about the overly large hammer of one of the requirements. Added UTI 43 about the meaninglessness of INPUT_UNIT's connect-team. - [181:44+] Deleted unnecessary and incorrect BNF limitations to the first constraint. Changed the BNF limitations on the others to the . - [208:4+] Did it before the example (the edit didn't say). - [213:18] Added UTI 44 about NEXTREC= and connect-teams. - [218:25+] Inserted "from the ISO_FORTRAN_ENV intrinsic module (ref)" after the first occurrent of IOSTAT_INQUIRE_INTERNAL_UNIT. Made item ISO-conformant. Rewrote excessive wordiness (with missing word) "if an error [condition] occurred due to a unit number identifying an internal file being used in an INQUIRE statement" -> "if a unit number in an INQUIRE statement identifies an internal file". - [221] Inserted new subclause title "Format specifications" for the first two paragraphs of 10. - [221] Deleted the paragraph in between 10.1 and 10.1.1, since it seemed essentially duplicative of the opening material. (If there is some subtle hint here that people want preserving, tell me what it is and I'll reword it into the opening material.) - [222] Inserted new subclause title "Syntax" for the initial material of 10.2 (which is indeed, basically the syntax of a format item list). - [225:15] Instead, prefixed "format control" with "However, ...", since the bare "Otherwise" implies negation of the whole condition instead of only the i/o list item half. - [226] Inserted new subclause title "General" for the initial part of 10.6, though all but the first (near-pure-waffle) paragraph is about character sets and file encodings, so a title about that might be warranted instead. Or maybe even split it into two subclauses if there is something valuable in the first paragraph. - [226] Inserted new subclause title "General rules" for the initial part of 10.6.1, which is indeed about the general rules. - [227:20+] Added UTI 45 about unacceptable exposition. Added UTI 46 about failure due to "unsigned" issue. Added UTI 47 about failure due to lack of integer kinds corresponding to every bits kind. - [227:22-23] the second "the list item" -> "it". - [228] Inserted subclause title "General" for the initial part of 10.6.1.2. - [233] Inserted subclause title "Overview" for the initial part of 10.6.4. - [237:42-43] Did something different so as to avoid a mangled sentence with two "and"s. And deleted the cross-refs which were the cause of the mangling. - [241:10+] Added UTI 48 about list-directed output of bits. - [257:25+] Added UTI 49 about explicit interfaces and co-indexed objects. - [264:19] Added R1214a and b as R1215a and b instead. - [265:15-18] Replaced the list of various ways of explicitly specifying SAVE by "may be confirmed by explicit specification.". If it's good enough for the type declaration statement, it's good enough for the procedure declaration statement. - [266:27+] Inserted the second alternative note. - [267:15-17] I did this but I'm not sure why it said to filter the procedure pointer case to the end. IMO listing all the simple cases first usually leads to more readable sentences. Of course what we'd really like is a simple term for the specific intrinsic functions that may be passed as actual arguments. - [268:2-15] Also replaced "may" in the penultimate sentence with "shall". - [269:13+] Added UTI 50 about a rather painful limitation and the implications on out aliasing rules. Added UTI 51 about an extreme over-exaggeration in a note. - [269:14] Omitted the second "the". - [269:14-15] Added UTI 52 about damaging pointer arguments. - [269:15] Also split this into two paragraphs, the first about pointers, the second about allocatables. - [269:16] Added UTI 53 about fake-polymorphic allocatables. - [271:12-] Added UTI 54 about co-array arguments. - [270:13] Did alternative edit. - [271:6] Added UTI 55 about co-indexed and ASYNCHRONOUS. - somewhere near here, added UTI 79 about dummy co-arrays. - [271:16-18] Also deleted "the specific name of", because we are now talking about the actual procedure that is associated, not its name (this is seriously wrong for procedure pointer components, for example, which are not "names"). - [280:5-] "prefix" -> "\si{prefix}" - [281:1] Reworded. - [282:26] Reworded. - [284:18,19] Reworded to be similar to [281:1] and [282:26]. - [286:9] Reworded to be similar etc. - [291:3] Moved the first paragraph, which is only talking about classifying intrinsic procedures, into 13.1 Classes of intrinsic procedure, before its existing first paragraph. Rewrote the second paragraph, moving it to be the new "General" subclause of 13.8 Standard intrinsic modules. Rewrote the material there. - [291:16+] Added UTI 56 about collective subroutine definition. Added UTI 57 about lack of "implicit team sync" definition. Added UTI 58 for incorrect placement and other inappropriatenesses of enormous witter. - [291] Introduced subclause title "General rules" for the initial part of 13.2. - [292:20-24] Rewrote a bit more. - [294:25+] "Inverse hyperbolic cosine" et al looked so weird in the table that I made them all "Hyperbolic arccosine" instead. - [297:4-11] Maybe when these get made into proper tables, describing what a reduction is and calling them all reductions would be an improvement. - [298:9+,11+,12+] Added UTI 59 about same name for different functions. - [304:14] Also changed wording to be the same as ACOS, otherwise this edit ended up with nonsense. - [304:18+] Changed typesetting of maths to use \pi/2 instead of \frac{\pi}{2}. We use the former almost everywhere. - [305:35+] Inserted after ATAN2, because I think "2" collates before "H". Changed formula typesetting to be more like existing formulae. - [306:13+] "approximation of" -> "approximation to", several times. - [306:14-] Inserted the new subclauses alphabetically, not where it said. Fixed poor capitalization of examples. "an implementation where the" -> "a processor whose". "an implementation that" -> "a processor that". "IEEE 32-bit" -> "IEEE single precision" Deleted "and default bits kind is 32". Added UTI 60 about useless ineffective KIND arg of BITS_KIND. Added UTI 61 about inappropriate result value specs of BITS_KIND. - [306:14-21] Insert grumble about "replace whole subclause" with a lot of changes just to make a simple conceptual change (and which is functionally useless). Didn't change the description, which seems correct as is. Added UTI 62 about useless ineffective *irritating* KIND arg. Grrr. Fixed capitalization in the examples, and inserted leading zeros to make it more obvious what it does. - [306:32] Fixed capitalization and spacing. - [307:26] Fixed capitalization. \coarrays J3/06-174r3: (NOTE: following this are some bits edits which modify this edit.) - [309:33-] Did this alphabetically instead of where it said. "NUM_IMAGES() has the value 2" -> "the number of images is two". (better not to mention what could be a user-defined statement function). "MASK has the values" -> "MASK is the array", actually, rewrote all these completely. Sigh. Changed "shall be ... of any type" -> "shall be ... and may be of any type". Fixed "where is the rank of CO_ARRAY" -> "where is the co-rank...". "indices of maximum values" -> "indices of the maximum values". Rewrote sentences with "a maximum value" since there IS ONLY ONE. Yes, there can be multiple images with THE maximum value, but there is still not more than one of them. Followed the MAXLOC model (roughly). Splat the "type character" sentence off into a new paragraph severally. I see CO_MAXLOC and CO_MINLOC are missing BACK= (or CO_BACK?) arguments. Removed "kind" before "type parameters" in CO_PRODUCT and CO_SUM. There seems to be no technical reason for not returning the upper bound of the last dimension of a co-array. They are not like assumed-size arrays at all, they have a perfectly good known (as in, determined by the number of images) upper bound. - [314:12-] Fixed summary table to agree with function descriptions. Fixed capitalization in examples. - [315:24+] "approximation of" -> "approximation to", twice. - [315:24+] "single-precision IEEE" -> "IEEE single precision". - variously: changed "component" of array to "element" of array. - globally: changed "shall not be scalar" to "shall be an array". changed many "shall be a scalar." to "shall be scalar.". - [316:23-] Fixed "MASK=A" -> "MASK=M". - [317:2-] Added UTI 63 about FORM_TEAM. Rewrote argument definition of TEAM, which was meaninglessly different in this case. - [319:11-12] Didn't do "number"->"value" here. If we're talking "largest" (and we are) we're talking *numbers*. - [319:20+] "approximation of" -> "approximation to". - [320:25] Fix capitalisation in examples. - [somewhere] Added UTI 64 about EOSHIFT of BITS. - [321:6] Fixed immediately preceding "has the result" -> "has the value". Also in ISHFT. - [321:18] Fixed capitalisation. - [321:29] Fixed capitalisation. - [322:19] Reworded. - [322:23] Fixed capitalisation. - [322:24-] Expanded examples. - [323:31-33] Combined second and third alternatives, slightly reworded. The result is not particularly easy to read, but might be correct. - [324:3] Reworded slightly. - [324:7] Fixed capitalisation. - [324:8-] Various rewordings, typo fixes. - [325:7+] Added a stupid example. - [326:17-] Reworded. Added UTI 65 about another stupid KIND argument. - [329:21+] Changed description. Inserted alphabetically instead of where it said. "approximation of" -> "approximation to". - [329:30] Reworded substantially. Added UTI 66 about the result not being a "value". - [330:2-] Fixed capitalisation in examples. - [331:17+] Fixed capitalisation. - [332] Fixed typo in MAXLOC example case (ii). - [334:7+] Added UTI 67 about inconsistency of MERGE_BITS compared with IAND. Added UTI 68 about internal inconsistency of MERGE_BITS. Fixed capitalisation in example. - [334:22+] Fixed capitalisation. - [339:4] Fixed capitalisation. - [340:22,24] Rejected edit - the existing text seems correct even for bits. - [340:26] Fixed capitalisation. - [340:26+] Greatly simplified the result value paragraph. If people are really interested in what the Frobenious norm is, we can go back to the J3/06-014r1 version or insert a note. - [341:30+] Reworded example slightly. Added UTI 69 about the poor "extra examples" here. - [342:17-] Various minor rewordings. - [344:8-9] Added UTI 70 about RANDOM_NUMBER description. - [346:16] Replace case (iii) with the first paragraph instead, and made the second paragraph case (iv). - [346:24] Fixed capitalisation. - [351:19+] Added UTI 71 about SHIFTA description. Added UTI 72 about SHIFTA result value wording. Fixed capitalisation in examples. - [356:1+] Gave permission for CO_ARRAY to be of any type instead of requiring it so to be. Deleted spurious ", and lies in the range 1, ..., NUM_IMAGES()". Modified the example. The second part of this is trivial tutorial stuff, suitable for the 2nd lecture in Parallel Programming 101. Perhaps this trivial tutorial stuff should be collected somewhere in c13? - [356:10+] Deleted "where the rightmost bit position is 0", because I believe this is already explicit in our bit model. If it's not, it ought to be. Fixed capitalisation in examples. - [360:3] Deleted "intrinsic". They are not intrinsic procedures. - [360:14-] Rewrote this one again. Did the change in c15 for C_PTR and C_FUNPTR. Added UTI 73 about IMAGE_TEAM (extra suggested edits). I noted in J3/06-014r1 "Consider acting on this if time permits."; well, time does not permit! - [360:17+] Inserted "equal to". - [360:33+] Inserted "equal to". - [391] Inserted new subclause heading "General" for the initial part of clause 15. New subclause heading "Summary of module contents" for the initial part of 15.1. - [391:25+] Inserted this after C_BOOL instead (following the general rule that BITS is the last non-CHARACTER intrinsic type to be mentioned). Added UTI 74 about the undesirability of these names. - [396:14+] Added after LOGICAL instead, following the general rule. - [402] New subclause "General" for first part of 15.3. - [403] New subclause "Definition and reference of interoperable procedures" for first part of 15.4. - [405] New subclause "Identifiers and entities" for first part of clause 16. - [409:15-410:4] Some rewording also needed and therefore done. J3/05-237r4: [409:26] 16.3, 3rd paragraph, 2nd sentence, replace "includes the FORALL" with "includes the FORALL statement or FORALL or DO CONCURRENT construct". {NOTE FROM THE EDITOR: Ugh. No J3 action required.} \block J3/06-142: [410:14+] 16.3, append paragraph to subclause "If a global or local identifier accessible in the scoping unit of a BLOCK construct is the same as a construct entity of that BLOCK construct, the name is interpreted within the BLOCK construct as that of the construct entity." - [406] New subclause title "Classes of local identifiers" for the initial part of 16.2. - [410:14+] Did boilerplate factoring-out. Added new paragraph about statement entities within constructs. We probably need something further about nesting of constructs within constructs and statement entities within the scope of other statement entities... - [410] Deleted opening paragraph of 16.4 because it is unnecessary witter. New subclause title "Forms of name association" for the initial part of 16.4.1. - [411:8] Didn't fix the (long-standing) problems in the first two sentences of this paragraph - this will have to wait. - [411:29+] appended "in a \si{define-macro-stmt}". - [414] New subclause heading "General" for 1st part of 16.4.2. Maybe a better heading would be "Pointer association and targets"? Or simply "Targets"? - Extra edit at [414:12] after "disassociated" inserted "or associated". - [414:18+] Did more substantial rewrite. Note that instead of duplicating lists of events we should have a single definition of "when default initialization occurs", call the action on the object "is default initialized", and then just say "is default initialized" everywhere instead. - [414:25] Did the insertion nearer the end of the item. - [415] New subclause heading "General" for the 1st part of 16.4.3. - [416:11+] Added UTI 75 about endianness. Added UTI 76 about bits definition and other types. - [416:28+] Added UTI 77 about subversion of portability. - [418:16-17] Also split this paragraph (which has now become quite long) into three, one for each type of association. - [419] Moved the initial paragraph on 16.5 to 16.5.1. - [420:3+] Extra edit to handle initially defined pointers. J3/05-278r2: (modified by J3/06-154r4:) [420:11-13] 16.5.5 Events that cause variables to become defined, numbered list, first item, Replace both occurrences of "variable that precedes the equals" by "variable". - [423:33] This edit was moot. - [423:42+] Fixed item 9. - [423:43] Deleted the list of statements instead. - [424:4+] Dehyphenated variable-definition context. - [427:1-] Changed definition of "co-array". Changed cross-reference of "co-bounds", changed wording. Changed cross-reference of "co-subscript". - [427:2+] This cross-reference is not very useful precisely because the information about collective subroutines is scattered instead of being combined into one definitive subclause. - [427:18+] Fixed spelling of input/output. - [429:11] Also sorted list into alphabetic order. - [430:26+] Fixed cross-ref. Added UTI 78 about global entities. - [436:1-] Fixed cross-ref. - [484:9+] "Section" -> "Clause". Reformatted examples. Made "global_sum_mask" valid (unspecified-intent co-array dummy). Put them both into a module since they need an explicit interface. These examples don't explain much to me: they need explanatory material saying what they do - and maybe in particular how GLOBAL_SUM(array,dim) differs from CO_SUM(array,dim). 5. Miscellaneous late editorial changes - Rewrote comment about bit sizes in c04, in particular: "aggressive optimization" -> "efficient execution". - Rewrote requirement about referencing the procedure IEEE_GET_FLAG et al within a DO CONCURRENT loop. This might need further wordsmithing. - Rewrote example witter for BITS_KIND. - Fixed (Snyder) The namelist-group-object at [198:27] (the second one in the paragraph) needs to have \si{} wrapped around it. - Fixed (Ingrassia): Section 13.4 said "for each type" where it meant for each *representation method*. - Removed "implement*" where it is used to refer to the processor, instead of its (normal?) technical meaning of a procedure. Only in normative text, most of the vague usage in notes is left. "a processor may have an implementation limit" (on the no. of labels) ->"a processor may have a limit" "Each implementation defines" (collating sequenc) -> "The processor defines" "implemented by the processor" -> nothing. "shall be implemented with at least one of the IEEE rounding modes" -> "shall conform with ..." (who cares how it is implemented, it is whether it conforms to IEEE that is the question!) The sentence is awkwardly phrased anyway to my mind, but further wordsmithing can wait. "is implemented in accord with" -> "conforms to". "If default reals are implemented as in the IEEE" -> "If default real type conforms to the IEEE". "processor implements SQRT in accord with the IEEE" ->"intrinsic function SQRT conforms to the IEEE", twice. Completely rewrote the "example" for IEEE_SUPPORT_SQRT since it was unnecessarily and redundantly duplicative of earlier text, except that it got it wrong (as in, what it said was a lie). - Deleted the note "An implementation may provide alternative versions of an intrinsic procedure..." in c14. This is equally true of various compile- time options etc., not specific to IEEE, and it is seriously misleading since nothing provides anything. The intrinsic is implemented by different rts routines in different cases, big deal. Yes, this could be rewritten to be correct, but it hardly seems worth it. - Fixed example in Annex C as pointed out by J3/06-104. However, this seems to be an unnecessary syntactic complication - we should consider fixing this during integration. - In c04, "specified for a component" -> "specified", twice. - In c01, New subclause heading "Applicability of requirements". 6. Incorporation of corrigendum 2 4.4.1 Appended "; this kind type parameter is of type default integer" to the preceding sentence instead. 4.4.2 Ditto 4.4.3 Ditto 4.4.4 (i) Made this a separate sentence instead of conflating value with kind. Deleted "Strings of different lengths are all of type character." as being spurious waffle (we've only just said type character provides strings with different lengths!). (ii) Appended "; this ..." instead. 4.4.4.1 Done as modified by the ballot. 4.4.5 Appended "; this ..." instead. 4.5.3 Added to "Default initialization for components" instead (the BNF has moved to there). 4.5.5.2 Done. 5.1 First and third edits moot by c05 rewrite. 5.1.2.5.4 Done. 5.2 Moot by c05 rewrite. 5.2.10 Moot by c05 rewrite. 7.4.2 (i) Done. (ii) Also changed constraint inserted on [143:23+] for the change of to include pointer function references. (iii) Done. (iv) Also capitalised "the" at the start of the constraint. (v) Also inserted constraint stopping from being a pointer function reference (since we take a component of it). 8.1.5.1 Done. 9.5.1.3 Done. 9.5.3.7.1 Done. 10.9.1 Done. 10.10.1.2 Done. 10.10.1.3 (i) Done. (ii) Rejected - this only applied to an earlier version of edit (i). (iii) Instead replaced "comma or between the comma" with "comma or semicolon, or between the comma or semicolon. Note: more substantial rewrite of this paragraph might be good. (iv) Done. 10.10.2.2 Done. 12.4.1.2 Done. 14.10.7 Done. 14.10.22 Done. 7. Enhanced Modules: further work following J3/05-168 Removed constraint C1111 as being inconsistent (only applied to submodules and not to modules). If we wish to consider reinstating this, it should apply to modules as well. UTI 5000: Changed "its descendant submodules" to "its descendants". (Actually, "its submodules" is not properly defined ... if it were, we could get rid of the term "descendant" completely and use "its submodules" everywhere. Wordsmith later? Defining it in c02 would probably be best.) Issue resolved. UTI 5001: Changed various "referencing a module or accessing a submodule" -> "referencing a module or submodule". and concomitant "access* ... module" -> "reference* ... module". Issue simplified (to being whether "accessing a submodule" is adequately defined; I don't believe so, but fixing this should be easy). UTI 5002: Changed module procedure interface bodies to *define* the module procedure interface, not simply declare it. Issue resolved. UTI 5004: Fixed (c02) definition of host scoping unit to work for submodules. Fixed (c16) Host association for submodules. Also fixed (c16) host association to work for all identifiers, not just names, by "has access to the named entities" -> "has access to entities" "known by the same name" -> "identified by the same identifier" Also fixed "host scope" -> "host scoping unit". Issue resolved. ===END OF DOCUMENT===