J3/07-283 To: J3 From: Malcolm Cohen Subject: Editor's Report for 07-007r3 Date: 2007 September 27 1. Typographical Changes (mostly fixes) - [19:41] Added missing right parenthesis. - [20:20] "parameyet"->"parameter". - [59:34] Fixed LaTeX typo. - [69:11] Removed extra 's'. - [168:26] Singularised "functions" for number agreement with line 19 (the start of the sentence). - [222:3] "may ... only"->"shall ... only". This ain't permission. - [253:1] Inserted "to" between "referred" and "by". - [323] "PROCEDURE"->"procedure declaration", twice. - [354:9] "inquiry intrinsic functions" -> "intrinsic inquiry functions". - [361] Marked POPCNT as E(lemental), not T(ransformational). - [451:11,12] "function" -> "inquiry function", twice. - [451:19] "inquiry" -> "inquiry function". - [453:28] "function" -> "subroutine". - [454:23] "function" -> "inquiry function". - [454:31] "function" -> "subroutine". - [455:2,3] "function" -> "inquiry function", twice. - [455:15] "function" -> "subroutine". - [455:16,25] "function" -> "inquiry function", twice. - [456:10] "functions" -> "inquiry functions". - [456:14] "function" -> "inquiry function". - [457:6] "function" -> "inquiry function". - [457:7] "SQRT" -> "the intrinsic function SQRT". - [466:2-3] "the function" -> "the intrinsic function", thrice. - [495:10] "2.1"->"image index (2.1)". - [510:21] "." -> ";". - [573] Moved the module to precede its submodule. - Lots: "INTENT("->"INTENT (", and hyperlink; while reviewing these, found defects in the IEEE module subroutine descriptions: added UTI 133. 2. Editorial Changes - 4.4.1 added paragraph specifying the kind type parameter KIND for all intrinsic types; 4.4.2 et al simplified the discussion accordingly. - Deleted term "type double precision real" - there ain't no such animal, it's type real with double precision kind, or just "double precision real" for short. Almost all references used the latter term anyway, only a few needed fixing. - Deleted term "type default logical" - it's "type logical with default kind", or just "default logical" (without the "type"). Hint: the value of the kind type parameter does not affect the "type", so there cannot be such a thing as a "default logical type". - Similarly default real, default complex, default character, ASCII character, ISO 10646 character. In many cases the new wording is an obvious improvement; in some cases more wordsmithing could be done. - Determified "belong"/"belongs" (yes, both existed - grr), deleted the corresponding glossary entry, and deleted the indexing. This is just the normal English usage of the word, it does not warrant being made into a technical term: furthermore, it is only used in this sense (viz applying to CYCLE & EXIT) in a very small number of paragraphs close together so does not need indexing anyway. - Deleted term "base type", which was not being used to any useful effect; yes, I actually reworded or deleted all the usages except in a comment. - Deleted glossary entry "class", which was never used with that meaning in the normative text. - Deleted term "shape conformance" completely - it was a useless synonym for the property of being conformable; also deleted index entry for "conformance" there. - Deleted glossary entry "conformance", which was an incorrect restatement of 1.4 Conformance (and the term is mostly used in the standard NOT with this meaning in any case!). - Deleted glossary entry "construct" which was just simply and completely and utterly wrong. It doesn't need to be a defined term, so I just left it at that. - Unindexed "DO CONCURRENT constructs!restrictions on", as it is completely pointless (the preceding 4 pages have various requirements, no-one is going to go to the index to look up these particular restrictions as opposed to the others). - Unindexed "DO WHILE construct" and "construct!DO WHILE", since there is no such animal (it's just a DO construct with a WHILE clause, we never used the term "DO WHILE construct" except in the index entry). - Made the hanging predicate in Note 4.10 (p63) into a comment. - Added processor dependent Annex entry for "initial underflow mode". - Termified: "direct component" and "ultimate component", "finalizable", "vector subscript", "disassociated", "inquiry function", "effective argument", "saved", "unsaved", "ultimate argument", "extended type", "extension type", "parent type", "binding label", "collating sequence", "collective subroutine", "component order", "connect team", "connected", "character storage unit", "file storage unit", "numeric storage unit", "unspecified storage unit", "storage unit", "team synchronization", "target", "characteristics", "construct entity", "default initialization", "default-initialized", "explicit interface", "effective item", "external file", "external unit", "internal file", "final subroutine", "finalization", "inherit", "inheritance association", "parent component", etc. - Determified "intrinsic procedure", as it is subsumed by "intrinsic". - Added UTI 140 about confusing terminology (effective i/o list item). And UTI 141 about "effective list item" - grr. - Added UTI 142 about unit numbers being the same across images. - Turned "external linkage" into UTI 143 since it is completely wrong. - Wrote a completely new definition of generic identifier, since the old one was just wrong for intrinsics. Ditto generic interface. I think I got these right, but doubtless more wordsmithing would be good. - "control mask" never was a special "defined term", it was just used with a particular meaning in WHERE. Deleted from glossary. - Deindexed "initialization" in favour of "initialization!default" and "initialization!explicit". - Determified "deferred binding", as it's only used in c04, and not very much there (mostly with cross-refs or in the section that defines it). - Index "construct entity" in the right place for DO CONCURRENT (which carefully avoids using the term, grumble), ditto SELECT TYPE. - Noticed that the "characteristics" definition was ambiguous: since there are two obvious fixes, added UTI 139. - Determified "characteristics of a procedure": none of the other "characteristics" subsidiary were terms, so this one does not need to be either. - Determified "global entity", which is basically only used in c16 (and a bit in c02 where it's referring to c16). - Deindexed "label!binding". All it did was to confuse the reader as to what "label" meant (we *NEVER* actually used it to mean binding label as far as I can tell). Why didn't we use "C identifier" or similar for this? Too obvious? - Determified "character string". People who don't know what a character string is shouldn't be programming. - Indexed "dynamic type" better (well, in more places anyway, in fact everywhere it occurred). Ditto "argument keyword", etc. - Deleted the glossary entry "deleted feature". Also, these were badly indexed (both singular and plural) - indexed properly as the plural (since we're always talking about them all together). Noticed that Annex B contains a straight-out lie about printing - added UTI 134. - Deleted the glossary entry "local entity", because it was just wrong. Furthermore, it was only used three times (now twice) in the whole standard excluding the glossary, and that was just with the normal English meanings of "local" and "entity". - Determinified "obsolescent feature", and indexed it properly (i.e. everywhere it is used, including Annex B). Should I index it to all the actually-obsolescent features themselves? It would be trivial to do so. - Deleted glossary entry for "obsolescent feature" as it doesn't add anything more to the basic description in c01. - Deleted glossary entry for "operation" as it was completely and annoyingly wrong. - Attempting to clarify some of the IEEE stuff, but found some more inconsistencies (and bad language): added UTI 136. - Deleted the term "many-one array section"; after deleting the redundant and dangerous duplication at [172:15], it was only used once; inserted the definition into the sentence that used it. Reworded definition to avoid the unfortunate ambiguity (it could be read as meaning X([1,2]) = something was not allowed if X(1)==X(2). The rewording is slightly clumsy, maybe it could be wordsmithed without reintroducing ambiguity. - Deindexed "subscript!vector" for now - it doesn't seem all that useful. It's pretty easy if slightly tedious to reinstate this. Obviously its index set should be the same as that of "vector subscript", and I've now properly indexed that. - Determified "invoke", which is being used with its ordinary meaning. - The first paragraph of 4.5.4.5 "Default initialization for components" ought to be deleted or stated in the singular; left alone for now. - Deindexed "subroutine!collective". It was the only descendent of subroutine, and is not more noteworthy than elemental subroutines, final subroutines, intrinsic subroutines, external subroutines, et al. - Changed various "use association or host assocation" to the much more common "use or host association". - [32:23] Deleted "-valued". - [61:13] Deleted superfluous "default". - [112:Note 5.22] Rewrote to avoid using "target" to mean "object with the TARGET attribute" instead of "target of a pointer". - [136:8-10] Rewrote three sentences into one sentence with a list, factoring out the first 10 words of each sentence. - [203:Note 8.13] "characteristics"->"properties" (avoid using a defined technical term with a meaning different from its definition). - [206:23] Rewrote R837 to apply to R846(select-type-construct) instead of R848(type-guard-stmt), changing the text accordingly. The previous version couldn't work since there was no "selector" in sight. - [206:25,28] Fixed BNF limitations from R848 to R846; maybe I ought to have just removed them, since they are superfluous (the constraint is written not to need them) and fragile! - [226:38] "access"->"input/output". - [235:25-26] Deleted ", which is the set of images that are permitted to reference the unit", because it is wrong. The external unit only even exists on the connect team - the same unit number on a non-connectteam image refers to a different external unit. Inserted a reference to the definition of connect team in c02. - [311:12] Deleted "linkage association (16.5.1.5)". Sorry, but this is just wrong - linkage association does not provide "access to entities in other scoping units". Just go and read what it actually is! (Hint: any C file ain't no scoping unit.) - [325:7-8] Fix references to be into c07 instead of just a couple of pages earlier (c07 is where it describes how these are referenced, c12 is just how they are declared). - [326:last line,327:second line (both in Note 12.20)] "save"->"retain" and "saved"->"retained" (to avoid possible confusion with the SAVE attribute). - [328] "with is not"->"and this is not" (it's an additional assertion, not just a descriptive predicate). - [330:23] "extension type"->"extension" (currently we have "type ... is an extension type ... of the type": that is too many types! We normally just say one type is an extension of the other.) - [353:5] Inserted "subroutine" after "collective"; collective is not a defined (adjective) term, "collective subroutine" is the defined (noun) term. - [353:6,8] Inserted "intrinsic" before "inquiry" twice for clarity: the preceding paragraph already said we were only talking about intrinsic procedures, and if one thinks that it doesn't just refer to intrinsic functions (say, maybe, the IEEE functions) then it gets interpreted for user functions as well, and ***IT IS WRONG FOR USER FUNCTIONS***. - [353:9] "not associated"->"disassociated". - [353:15] Deleted "Some intrinsic subroutines are collective subroutines." We already say this at line 5. (And I reworded the description as part of termifying anyway.) - [359:EXTENDS_TYPE_OF] "is an extension type (4.5.7) of the dynamic type" ->"is an extension of the dynamic type" ("extension type" is a defined term so we don't need a cross-reference, especially in the middle of a summary table, and we normally just say "extension of" especially when there are two other "type"s in the sentence). - [392:22] Deleted "type (4.5.7)": we don't need cross-refs for basic concepts that are defined terms already. - [398:19] Changed HYPOT example (previous one had insufficient digits). - [454:31-32] "inquire which rounding mode is in operation" ->"get the current rounding mode" [454:32-33] Deleted "Its value ... Standard." (simpler wording avoids using "inquire" for something that's not an inquiry function, and its the same wording as on the procedure itself; deleted the second sentence because it is unmitigated nonsense - a subroutine does not have a value!) - [455:15-16] "inquire which underflow mode is in operation" ->"get the current underflow mode" (simpler wording avoids using "inquire" for something that's not an inquiry function, and its the same wording as on the procedure itself). - [455:16] "_MODE"->"_CONTROL". - [455:32] "saved"->"stored" to improve clarity. - [455:35] "saved"->"obtained" ditto. Maybe "obtain" is the verb we ought to be using for all those IEEE_GET procedures. - [456:Note 14.6] "saved and restored"->"obtained and set", twice. - [456:14-25] Split into three paragraphs, the third being the middle sentence about division, the second being the sentence after that, and the first being the bit before division. The second sentence of the first paragraph has an internal list separated by semicolons -- changed it into a list. The second para does nothing except contradict the first (presumably no-one spotted it before because the paragraph was unreadable all jumbled together) so I added UTI 135. - [457:5-6] "-0.0" -> "negative real zero", twice; we are not consistent about this (yet), but we use the words more often than the mathematical nonsense. - [457:14-15] Replaced this paragraph which attempted to import semantics from c13 (badly, since the procedure classification there is *EXPLICITLY* called out to be for intrinsic procedure only!) with text describing the actual semantics. - [461:1] "of INTENT(OUT)" -> an INTENT (OUT) argument". - [495:7] Deleted "7.2.3" (Masked array assignment - WHERE), since that does not have any construct entities. The reference to 8.1 instead of to the specific constructs that have such entities is useless, but I left that alone. - [504:6-7] "local object that is not accessed by use or host association" ->"local variable" - [504:18-19] Ditto. - [504:43] "local entity that is explicitly declared in the BLOCK" ->"construct entity of that BLOCK construct" - [509:10] "characteristics"->"properties": we don't mean just the characteristics here, using the same word as the ternical term can lead to confusion. 3. Meeting Papers 07-239r1 Done 07-240 passed to /EDIT, responses to suggestions [222:5] Went ahead and deleted this paragraph, despite some misgivings. The clincher is that it contradicts the last sentence of the preceding paragraph, unless one thinks that one can "prepare" a record without reading or writing it! If so, I haven't a clue what "prepare" can possibly mean. [222:30-223:2] yes: "has"->"is opened using" [226:35-227:19] I agree there is a problem, but I didn't change anything because the edit description was too vague. Try again. [230:22] I did this at [230:20] as well, thus four times. [231:25-28] Didn't do this - I think the previous paragraph probably wants rewriting as well (it contradicts itself). DEFERRED to m182/JOR (that's JOR at meeting 182). [231:29-30] REJECTED. Paragraph has a different meaning, it is not a duplicate. [231:19-22,23-25] DEFERRED to m182/JOR for consideration. [234:17] REJECTED. Existing text ok, suggested replacement bad. [234:39] REJECTED. Unmotivated Technical Change. [236:18] REJECTED. Outwith the scope of the standard, in fact we do not want to require this (in fact it's not necessarily possible). [236:23] Done. [238:22+] There isn't one. [239:2,3] REJECTED. Ok as is, suggested replacement incorrect (that is not the correct BNF rule to limit the constraint to, and given the wording of the constraint, it does not need any limiting anyway). [239:10-12...240:1] DEFERRED all of these to m182/JOR. [240:Note 9.29] Done. [240:21,240:25] DEFERRED to m182/JOR. [243:11] DEFERRED to m182/JOR. [244:3-4] REJECTED. C933 is broken - a variable is a data object, a procedure pointer is a procedure. Added UTI 132. [245:7-9] DEFERRED to m182/JOR. [245:13] REJECTED this Technical Change. Providing a useless facility that errors at runtime instead of compile time is, well, useless. Also, there are other technical reasons for not wanting this facility. [245:17-20 etc.] Done. [248:25-26] Done. [248:30] REJECTED - ok as is. [249:27,33] DEFFERRED to m182/JOR. [254:9] REJECTED - "therefore" actually means "for that reason", and is precisely the word required here. [254:34] Done. [257:14] Did "colon or data" instead, which seems to read more smoothly. [258:14,15] REJECTED - unnecessary. [258:26+3] Done. [259:9,12-13] Done. [259:18-19] REJECTED - unnecessary to limit the constraint and the suggested BNF rule is incorrect. [261:2,3] REJECTED - unnecessary. [261:11-14] DEFERRED to m182/JOR (the suggested replacement sentence is long and complicated - even worse than what's there now!), except for the edit in the second sentence, which I did. [261:Note 9.62] Did a different edit instead, to make it more like our other examples in the i/o clause. [263:23...264:31] REJECTED. These paragraphs can be cleaned up, but these edits are not in the right direction. [267:21] Tried to rewrite the sentence to sound better. [269:34] Done. [269:36] Done. 07-241r1 All the cannonball polishing: DEFERRED. [279:31] Did this edit to [278:31] instead - you're lucky I found it! Anyway, the edit is moot. [279:36] Edit moot, but I did it anyway (to the dead text). [279:41] REJECTED - this sentence should be a paragraph on its own. I made it a paragraph on its own (in the dead text). [282:Table 10.1] Done. [282:1-2] REJECTED - I believe this was covered by another paper. [285:8] Done. I made this into a \si, so it will get hot-linked to the syntax term that it is, as well as being indexed as a usage of the syntax term. Many (not all) of and in c10 have been done as \st which just sets the font and neither hyperlinks nor indexes. Maybe I should change all of those to \si? Ditto ? [289:24] Done. [291:29-30] No, moved to [278:16+] as a new paragraph, and changed "mode" to "decimal edit mode" as well. [294:9,297:33] REJECTED - why does it not work? 07-243r1 Hey, did we vote specs and syntax for this feature creep? It's premature to vote edits before we vote the functionality! I went ahead and did it anyway, since this kind of minor cleanup is what we're supposed to be doing this time around instead of adding large major new features, but we should be making sure we are doing it deliberately and not in our sleep. [279:26] Inserted missing comma in list of edit descriptors, put list into same order as used elsewhere in the numbered list (yes, that's not alphabetical but we should change all of them or none), singularised edit descriptor (only one is being used - see the original text). 07-244 Done. I did the second extra edit (to 306:27). Instead of the first extra edit (to [303:12]) I deleted C1101 completely. RETURN and ENTRY statements already constrain themselves to appear only in subprograms, we don't need to constrain a main program not to contain them. A main program cannot contain an IMPORT statement or an END MODULE statement but we don't bother to constrain those! The ENTRY constraint is C1265; the RETURN constraint is C1269. 07-245r2, Part 1 only I deleted the entirety of Note 12.8, not just the second paragraph, because clause 12 doesn't seem to be the place for random wittering about some improvement that was made in the PREVIOUS Fortran revision. Also moved Note 12.7 from the middle of the subclause to the end where it belongs (yes, it actually fits better at the end, as well as better complying with the ISO guidelines). Changed the second "with" at [321:15], not the first: the edit ought to have said to replace "distinguishable with" by "distinguishable from". [331:1-2] Inserted "or an array pointer" instead: there is no such thing in Fortran as a pointer array (in the sense that everyone else uses it, viz meaning an array of pointers). Fixed the opening line of the constraint too. Added UTI 137 because ALL STOP does not seem integrated with i/o. Done. 07-251r1 Done; used wording "that is being opened" and "that is open" for the OPEN and CLOSE cases to capture the action vs state distinction; deleted UTI 112. 07-253r3 Done; deleted UTIs 117 and 118. 07-254r1 Done; fixed capitalisation of "INTENT (OUT)"; but now the paragraph is hard to read and opens up the question of why these are not being described as elemental since they self-evidently are; modified UTI 119 accordingly. 07-255r2 Done; deleted UTI 120. 07-256r1 Done; deleted UTI 121. 07-257r1 This does not even begin to address UTI 125, the purported topic of the paper; it makes no change to the (apparently) erroneous statement on p32, nor does it appear that anyone reviewed my rewrite of the text as I requested (or if they did, no-one said). Therefore UTI 125 remains totally unchanged by this paper. Added UTI 129 about the spurious reference to this note. This note is pretty useless anyway, and made even more obviously so by this paper - added UTI 130 about that. The second edit talks about unordered segments, immediately inviting but not answering the question about ordered segments; added UTI 131 about that. 07-258 Done; deleted UTI 126. 07-261r1 It would probably have been easier (and more transparent to the voters) to shred C.12.2 in its entirety and insert something sensible. I couldn't find module FNT_C_1 so I deleted module FTN_C_1 instead. I deleted the blank like the edit implied I should preserve. I deleted the spurious paragraph break the edit implied I should preserve. Inserted blank between INTEGER and (C_INT), several times; we are not completely consistent about this but we usually do it... Changed "int pointer" back to "pointer to int", which is the phrasing we used before and still seem to be using in surrounding text. Also changed "NAME specifier" to "NAME= specifier" (existing text). Also put the invocation of C_LIBRARY_FUNCTION all on one line. Also, in existing text, changed 'C_LIBRARY_FUNCTION' to 'C_Library_Function' to ``c_library_function'' to ``C_Library_Function'' because: (a) according to the preceding words these are names not strings - so quote properly, don't turn them into character literals (b) the binding label (name!) of the function without NAME= would have been the all-lower-case version, not the all-upper-case one - so use all lower case. Also changed FTN_C_2 (which is now a very poor name for the module, not that it was a particularly good one before) to CLIBFUN_INTERFACE. [588:2-5] Put "sendbuf" into code font (\cf) since that seems to be what we do for C variable names in surrounding text. Similarly for the other two replaced paragraphs. It was very tempting to change C_LIBRARY_FUNCTION to CLIBFUN and reformat the (quite poorly formatted) FUNCTION statement, but I managed to restrain myself this time -- hopefully someone else will look at this and make more changes because despite the massive improvement made by this paper it still looks as if it were carelessly thrown together. Done; deleted UTI 124. 07-262 Done. 07-263 Done; deleted UTI 122. 07-265r1 Done; deleted UTI 102. 07-270r2 Deleted cross-ref for "ultimate argument"; this is going to be a defined term anyway. Rewrote the sentences - the definition of ultimate argument isn't "of" a dummy argument, it just "corresponds" to one. Inserted more "shall"s in the RESULT argument paragraphs to make them read better. Added UTI 127 about impossibility of different objects being the same. Added UTI 128 about the lack of cross-image shape conformance. 07-273 Done. 07-274r1 Done. (Conditionally under boolean FeatureCOFINDLOC, just in case.) 07-276r1 REJECTED. The problem is not that procedures with dummy coarrays are interoperable, the problem is that coarrays are interoperable. Make them noninteroperable and the existing wording which requires interoperable dummies would handle this already. Therefore, fix the initial paragraphs of 15.3.5 and 15.3.6 (07-007r2:p487) instead. FM "Delete macros (but not BLOCK)" Done. Changed name of c03 to "Lexical tokens and source form". FM "Delete BITS except for bit manip funs that apply to ints" Done; these functions are DSHIFTL, DSHIFTR, IALL, IANY, IPARITY, LEADZ, MERGE_BITS, PARITY, POPCNT, POPPAR, SHIFTA, SHIFTL, SHIFTR and TRAILZ. Note that I had to invent some extra examples for some of these (arguably those previous example sections were deficient in not having any integer examples); those examples might bear some improvement. sv "Try indenting subsidiary items in c02." Well, I tried, and they don't want to. Sorry about that. Next time (if I remember) I will have another attempt to change the macros I use to achieve this, but it's not worth spending more time on it right now. ===END===