J3/14-106r1 To: J3 From: Malcolm Cohen & Stan Whitlock Subject: Editors notes for 14-007 Date: 2014 February 11 0. Introduction to 14-106r1 =========================== The combined /JOR and /DATA subcommittees, hereafter designated /JATA, processed 14-106 from Malcolm Cohen at J3 meeting 203. /JATA agreed with many of his ACTION and COMMENT items and those are specified as such embedded in the text below. Some items need to be adddressed by edits to 14-007 - those will be collected in a separate paper that references 14-106r1. >> items marked ??? still need work 1. Introduction =============== This document records alterations and changes to the edits specified by 13-008r1 made in the course of applying them to SD-007. There are a few action items for the committee, marked ACTION. I have a few comments for possible future action, marked COMMENT. I made a few additional edits I thought were needed, and closely enough related to a paper to bring it within editorial remit; these are marked EXTRA EDIT. I did quite a lot of extra hyperlinking and indexing whilst editing. In particular, many specifiers are now hyperlinked and better indexed. Perhaps I should do all the specifiers (but I ran out of time this time). 2. Notes with action items ========================== 2.1 Editorial and corrigenda 1-2 changes, 13-008r1 ================================================== [c13-c15] Also unindexed IEEE_, and indexed IEEE_ARITHMETIC et al instead, as the whole relevant page range. Replaced indexing of "ISO_FORTRAN_ENV module" at the beginning of its section with definition-indexing of its entire definition. Replaced indexing of "ISO_C_BINDING module" ditto. Sadly, "definition" indexing does not embolden page ranges. Indexing "C_(c type)" is probably pointless now that we index all the actual constants, but I left it. ACTION: Someone should express an opinion as to whether this last should go or stay. /JATA: it should go - please remove "C_(c type)" from the index [24:9,10,11+] "I/O" -> "input/output", "or to be" -> "and to be". Added a "hyperlink to syntax term but do not index" macro, used in [24:9.10.11+] to hyperlink to R1010 without indexing. [45:24+] Also changed number of columns in the table from 2 to 3; this made it fit on a single page (for now anyway). [46:29] Also indexed statement label at [45:22] "A blank shall be used to separate ... labels ...". [62:19] "type parameters" -> "any type parameter". {Use singular rather than plural, avoids question of whether one type parameter is ok and only 2+ type parameters that is bad!} [63:1-2] Also did the same edit at [62:23]. [76:10-] Also moved note 4.49 to the end of the subclause (was between p9 and p10), rather than leave it attached to the wrong paragrah or mid-subclause. [76:10] Did not insert "(7.2.1.3)", because the new p1 will also talk about intrinsic assignment so the reference belongs there. Inserted "statement" after "intrinsic assignment", because all the other occurrences of "intrinsic assignment" here have "statement" attached (surely all need "statement" or none?). ACTION: THIS NEEDS TO BE CHECKED. /JATA: agree that all need "statement" - 14-007 ok [76:25-26] Inserted "(7.2.1.3)" after "intrinsic assignment statement is executed", because this gets moved to be p1. Inserted "variable" after "allocated allocatable". [97:13] Instead changed "An entity with the INTENT(OUT) attribute" to "An INTENT(OUT) dummy argument of a nonintrinsic procedure", as the original sounded like the nonintrinsic procedure was the thing with the INTENT(OUT) attribute. [109:16] Also indexed "internal subprogram" and "module subprogram" here. Added new LaTeX macro \linkedmindex{text}{ref} to index text that is hyperlinked somewhere else. (We have special-case versions of this already for statements, constructs, syntax rules, ..., this is the general version.) Throughout: I have finally stumbled on a cure for the hyperlinks to syntax terms jumping to the wrong place viz just past the first line. I did not notice any adverse side-effects. [111:19-20] Also hyperlinked a few more terms without indexing, and hyperlinked "implicit typing rules" to the IMPLICIT statement with indexing. [intro] Replaced with updated text. This will need further updating after Corrigendum 3 comes out, and if the coarray TS comes out ahead of F2015. All the feature descriptions removed. [PDF properties] Updated PDF document title from J3/10-007 to J3/SD-007 to future-proof it. (Hardly anyone looks at these, so it does not IMO need to say the year, but it should not be incorrect.) [124:4-7] Hyperlinked and indexed "final subroutine". Hyperlinked "finalized" to "finalization", & indexed the latter. [124:9] Hyperlinked and indexed "definable". Hyperlinked "defined" and "undefined" without indexing. [126:31-33] Hyperlinked ALLOCATE statement to the BNF without indexing. [127:5] Hyperlinked "kind type parameters" and "type parameters" without indexing. [127:18-19] Hyperlinked and indexed "coarray". Hyperlinked ALLOCATE statement without indexing. Hyperlinked C_PTR to its definition, making a new hypertarget TYPE:C_PTR, and indexed C_PTR; similarly C_FUNPTR and LOCK_TYPE. Hyperlinked "subcomponent" and "dynamic type" without indexing. [128:24-26] Hyperlinked polymorphic, dynamic type, and declared type, all without indexing. Hyperlinked length type parameter in the preceding sentence without indexing. [128:28] Hyperlinked ALLOCATE statement to the BNF without indexing. [130:23] Hyperlinked "argument associated" to "argument association", and indexed the latter. Hyperlinked "dummy argument" without indexing. Hyperlinked "construct associated" to "construct association", and indexed the latter. Hyperlinked and indexed "associate name". In the preceding sentence, hyperlinked/indexed "pointer" and "undefined". EXTRA EDIT: [130:26] "it is deallocated" -> "if it is allocated it will be deallocated". ACTION: Check this for technical correctness. /JATA: extra edit is ok [130:27] Hyperlinked "local variable" later in the sentence, without indexing. [131:12] Hyperlinked "processor dependent" and "subobject" without indexing, and "allocatable" with indexing. [131:27] Hyperlinked "pointer" and "target" with indexing. Hyperlinked "subobject", "dummy argument", and "associate name" without indexing. Hyperlinked "argument/construct associated" to "argument/construct association" respectively, with indexing to the latter. [150:17-18] Hyperlinked "local variable" and "BLOCK construct" without indexing. [151:13-15] Hyperlinked "scoping unit" and "host scoping unit", without indexing. [152:6+] "A"->"a", "."->",". Hyperlinked "ultimate" to "ultimate component" with indexing, "pointer" to "pointer" ditto, "disassociated" without indexing. [152:26-28] Hyperlinked "scoping unit" and "host scoping unit", without indexing. [159:30-33] Deleted indexing of "bounds remapping" as being unnecessary given the indexing of the syntax term . Hyperlinked "bounds" to "bound", with indexing. Hyperlinked "extents" to "extent", without indexing. Hyperlinked "undefined" without indexing. EXTRA EDIT: [159:34] "is specified" -> "appears", for consistency with the preceding edit. ACTION: Check for correctness. /JATA: extra edit is ok EXTRA EDIT while doing [168:4-5], also changed "assignment statements" to "assignment or pointer assignment statements", and hyperlinked (with indexing) to the statements. (An alternative would be to use "forall assignment statements", since that actually does cover it properly.) ACTION: Check for correctness. /JATA: keep this extra edit, not the alternative [171:12] Hyperlinked with indexing: "associating entity", "definable"; without indexing: "defined", "undefined". EXTRA EDIT: [175:35] "transfer of control"->"branching". {[175:40] changes this in the obsolescent p2, but not in the active p1.} ACTION: Check for correctness/agreement. /JATA: extra edit is ok [175:28-29] Also deleted "a statement", changed "to a" to "and the branch target", and deleted "that", so that the result matches the putative result. [178:13-14] "either shall"->"shall either" EXTRA EDIT: same at [178:8-9]. Why? Because this was the ONLY PLACE in the entire standard where we used the strange wording "either shall ... or shall". COMMENT: I also consider "or shall not"->"or not" in both places, but I think it is very slightly clearer with the "shall" repeated. ACTION: Check for correctness. /JATA: extra edit is ok [178:17-18] "indeterminate"->"processor dependent". Why? I think this is trying to make this processor dependent. I can't think of any other plausible interpretation of the word "indeterminate" in this context. ACTION: Check that this appears appropriately in Annex Y. /JATA: That should be Annex A.2 "Processor Dependencies". Edits are proposed in a new paper. [216:32-36] Retained the existing indexing of "synchronous input/output", "asynchronous input/output", and "wait operation". Hyperlinked "defined" to its definition. [227:15,17-18] Changed the first "record position" to be simply "file", so it reads "... cause the file to be positioned before ...". COMMENT: (1) "file position to be positioned" was clearly bad. (2) This sentence is crying out for a complete rewording. ACTION: Check for correctness. Maybe reword it? /JATA: edit is ok - no rewrite needed [243:3-5] Added a comma after "IOSTAT=". COMMENT: We made this edit (F08/0096) because of a nitpicky reading (especially of "depend"); but the same nitpickiness still leads to trouble, e.g. INQUIRE(FILE='fred',EXIST=exist) is not allowed because the value of EXIST= depends on the value of FILE=. ACTION: This needs to be reworded since it is still completely wrong. /JATA: This is from F03/0096. See 14-007 [245:8-11] ??? [249:11+,19-20] EXTRA EDIT: Removed cross-reference to (9.5.2) in p8 since we just added one in p7. Hyperlinked "changeable modes" to 9.5.2 instead. (Also, "changeable modes" is in the index.) [258:15-20+8] "value is a zero value" -> "value is zero". Modified spacing/maths mode to improve typesetting. "10**(s-1) <= N < 10**s" -> "10**(s-1) <= ABS(N) < 10**s". [279:11-17] "the the scoping unit" -> "the scoping unit". [281:11-12] "is specified previously" -> "was specified previously". [292:16] Hyperlinked some stuff. [293:10-11] Wrong line number, should have been 7-8. Fortunately the paragraph number was right. Also the edit was out of sequence in 13-008r1. [293:5] Hyperlinked stuff. [293:10] Also changed "default character or of type character with the C character kind" to "of type character with default kind or C character kind". [309:23-25] "a module subprogram" -> "a " (statement is only true of this kind of module subprogram), "body, it" -> "body. It" (break excessively-long and confusingly run-on sentence), "result variable name" -> "result name" (not necessarily a variable, allegedly), and moved NOTE 12.44 to the end of subclause 12.6.2.5 (The content of the note had nothing whatsoever to do with the text that it was immediately following!) ACTION: Check correctness. /JATA: Much changed between 12-007 [309:22+-25] and 14-007 [312:32-35]. 14-007 looks ok [310:20] While looking at this, I noticed that p7 is a copy of p8 except for being wrong. I traced this back to a botched edit for 06-363r2 - this was addressing UTI 083 (which was complaining about p7 being wrong) but that paper specified an unacceptably unwieldy edit, so I did a simpler edit. But I accidentally left a copy of the original paragraph in the 007. Therefore ... EXTRA EDIT: [310:15-17] Delete. [310:20] And looking at the old UTI 083, I see that this new edit (from Corrigendum 2) is wrong in the same way - it takes no account of statement or construct entities. Reworded. ACTION: This really does need to be checked for correctness! /JATA: This is from F08/0058 in Corr 2. CF 12-007 [310:15-23] with 14-007 [313:25-33]. Edits are proposed in a new paper. [310:23] Reworded as this addition was also defective in the same way. Note that I deleted the "unless that" part as this is what is already covered by the appearance of the "function result" rather than the appearance of its "name". ACTION: Check for correctness. /JATA: rewording is ok [312:21+] "INTENT (OUT) argument" -> "INTENT (OUT) dummy argument", for consistency with the edit for [312:23+]. [312:23+] Inserted at 312:21+ immediately after the new constraint just added, to keep the dummy argument constraints together. [313:4-5] Also changed ", shall not" to ", and shall not" earlier in the sentence. [313:5+] Added cross-reference to the "Specification expression" subclause after the first mention of "specification inquiry" (this is not a defined term, and although it is indexed it has no convenient hyperlink so a proper cross-ref seems appropriate). [313:5+] (F08/0018 edit) Singularised the first sentence "actual arguments" -> "each actual argument" etc. Also "shall only appear" -> "shall appear only". [314:14-17] This leaves the paragraph as a single sentence, with an unfortunate beginning. Therefore... EXTRA EDIT: [314:14] "In the case that" -> "In a reference to an elemental subroutine, if". EXTRA EDIT: [320:top+11] COUNT intrinsic, "Reduce logical array"->"Logical array reduced". {Describe the value of the result, not the action.} [320:bottom-1-2] [321:top+4-5] [321:top+16-17] Also changed "Reduce array" -> "Array reduced". {Describe the value of the result, not the action.} [321:top+21] [321:top+22] Also dehyphenated "end-of-" because it is not qualifying a noun. EXTRA EDIT: [323:top+9] SUM intrinsic, "Reduce array" -> "Array reduced". {Describe the value of the result, not the action.} [324:1] "The functions ... are" -> "A function ... is" (needs to be singulare because the rest of the sentence is). [324:2] This is still not a comprehensive list - for example, it does not include procedure pointer assignment via derived type assignment. ACTION: Make list more comprehensive, or turn it into "Note that a function listed in blah is not permitted to be used as an actual argument or in many other situations where an actual procedure is expected to exist." Or just "... in many other situations.". /JATA: This needs some rewording to start and an new UTI to finish the comprehensifying o the list. Edits are proposed in a new paper. [324:3+0-325:1-0] Lowercased second and subsequent words in headings. EXTRA EDIT: Changed the entry for ATAN to put ATAN (X) in the Generic name column as it does not make sense otherwise (does not make much sense anyway). [330:36+] was very annoying to do, as the way the "incase" environment was set up I could not do references into roman numerals. Ended up creating a new environment from scratch to overcome the problem. [344:13-14] While I was looking at this I decided that the preceding text was defective and that the pseudo-table ought to be a real table. EXTRA EDIT: [344:11-14-] "maybe be absent" -> "is permitted to be absent only" (we do not say otherwise that it is required to be present, we just fail to give semantics for that!), "table and, in this case," -> "Table 13.4, and in this case" (excessive commas in strange places) "value shown converted, if necessary, to the kind" ->"value shown, converted if necessary to the kind" (ditto), new table 13.4, boxed, columns centred as that looks better, NOTE: We use "false" instead of ".FALSE." for Logical type, and that is fine, but then why do we not use plain zero or "0 + 0i" for Complex type? Surely we should use all Fortran syntax or all maths syntax, not mix them up. /JATA: yes, we should change "false" to '.FALSE.". Edits are proposed in a new paper. [348:13] Also fixed subscript i_th instead of superscript i^th, twice. [350:22-23] Actually affects lines 21-23. [350:24-25] "value 0" -> "value zero". {We are not consistent about this, but I think this reads better.} [351:22] Context is just *before* TRIM_NAME para, not *in* TRIM_NAME. [356:18-24] "initialization" -> "constant", "has the smallest" -> "has the value of the smallest". [360:14] I note that the "for i = 1 to n, where n is blah" is completely unnecessary since the Result Characteristics establish the size of the result as being that n. This is true in many places. However, I made no edit. ACTION: Review and simplify if it would not be confusing. /JATA: we don't find it confusing or unnecessary - we suggest no change [367:10-11] Did not insert extra "equal to". [367:14] This made the already overly-long call to MAXLOC become totally hideous, so I completely reset that... The line numbering package cannot handle it well, so there is one line number for 5 lines, but visually it is much better than the alternative. [UBOUND] (applying [367:etc] to UBOUND mutatis mutandis) The existing text for Case (i) of the result was much worse written than that of LBOUND, so I rewrote it completely to parallel that of LBOUND. [378:30-31] Old text in the edit was wrong, but the intent was clear so no problem doing the right thing. [394:27] I already did this automatically without thinking, as part of the [UBOUND] edit. [395:11] Ditto as part of [UCOBOUND]. [399:11] Also changed "BIND (C) attribute" to "BIND attribute"; there is no such thing as a "BIND (C) attribute". However, this entire sentence is completely redundant, since the things it says LOCK_TYPE is not are already prohibited by the fact of it being extensible. ACTION: Review; either delete or, if it is thought useful to bring these facts to the user's attention, the sentence should probably begin "Note that it does not" or "Therefore it does not". /JATA: we prefer to keep the info. Edits are proposed in a new paper. [406:15+] While I was adding lots more hyperlinks in this vicinity, I noticed that all the intrinsic module procedures that are hyperlinked need manual \label definitions. Created new macro \imodproc to do exactly the same as \insubsection except that it also adds the necessary label for cross-referencing and hyperlinking intrinsic module procedures. [425:19+] Set the literal code fragments ".TRUE._C_BOOL" ... "(_Bool)false" in code font. QUESTION: Do the specific requirements on C_BOOL not belong in the C_BOOL paragraph (old p4, new p5) instead of up front? /JATA: we think it's ok as is - [14-007 431:22-23 vs 432:4]. Paragraphs 2-4 describe what the values mean and 5-7 describe what their values are or are not if not available. [431:11-] Read through the other constraints here and ... EXTRA EDIT: C1504 before "derived type ... " inserted " that defines a" since it is the derived type definition that has a type-bound procedure part, not the type that it defines. [442:4] I went ahead and did this, even though 13-008r1 has a note saying this contradicts other rules about scopes. I need to find my earlier notes to check what I thought the contradiction was... ACTION: Review for possible contradiction. /JATA: we have no idea what contradiction Malcolm found. So as to not lose this item, we will make it a UTI. Edits are proposed in a new paper. [448:42] Also hyphenated the one at [448:44]. [456:29-30] Investigating the reason for this (no space between bullet and item text), it is because our "enum" environment deliberately! sets the space between the label and the item text to zero. This "works" when the label is left-justified within the label field (which it is for the enum environment) but not when it is right-justified within the label field (which it is for the bullet list environment). This can be fixed by reinstating the label separation and subtracting it from the label width, but while I was looking at that, I thought that the enum environment was wasting too much space anyway, so I made a "newenum" environment which uses a bit less space (as well as having this fix), and used that to set the list in 16.6.6. Having done that, I also thought that within an enum list, a sub-bullet list would look better if the bullet were centred within the label field instead of right-justified, so I made a new macro "nesteditemize" and used that for this particular list. ACTION: Review layout (spacing) of 16.6.6, compare with 16.6.5, and decide which is better, and set all such lists using the one best liked. NOTE: There is scope for reducing the margins even more, especially for nested lists - there is still a lot of space following the "(a)" or bullet. I can tweak the lists further if desired... /JATA: 12-007 [453 & 455] vs 14-007 [460 & 461]: we prefer the spacing as it is on 14-007 [462:6+] Added reference () to both items (that is GET_COMMAND_ARGUMENT). [Annex B] I interpreted "appropriately" rather extensively... (a) new subclause "1.6.1 Previous Fortran Standards", (b) made the list of standards into a proper table, (c) new subclause "1.6.3 Fortran 2008 compatibility", currently says fully compatible - this could change! (d) [24:3] deleted "informally known as" since that is now redundant with the immediately preceding table, (e) [24:9-10] deleted "the previous ... Standard," since Fortran 2003 will no longer be the previous standard. 2.2 Papers from meeting 202 =========================== 13-304r1. [Introduction p2+] ". Diagnosis" -> "; diagnosis". {So that the feature is described in a single sentence.} [282:6-15] Indexed "module procedure interface body" here, even though the text does not mention those words, because the text defines how host association works for module procedure interface bodies. [443:27-31] Inserted an extra sentence (after the new first sentence): "In the case of an internal subpgrogram, the access is to the entities in its host instance." 13-307r2. [Introduction p2+] Completely rewrote the description to list all the affected functions. 13-308r2. [Introduction p2+] "SIZE= is allowed"->"The SIZE= specifier is permitted". [216:32,35 9.6.2.15p1,p2] Instead of first deletion, "a nonadvancing" -> "an". 13-309r1. EXTRA EDIT: While looking at 10.7.5.4 I noticed that the indexing of "data edit descriptors" stops after the G edit descriptor instead of after the DT edit descriptor; moved it. 13-330r1. [intro] "The value return[sic] by INQUIRE RECL=" -> "The value assigned by the RECL= specifier in an INQUIRE statement". 13-331. [intro] "occur in a PURE procedure" -> "appear in a pure subprogram". 13-332. No changes. 13-299r1 parts 1-2. No changes. 13-320r2. EXTRA EDITS: [44:27-28] Set last bullet point in 3.2.5 entirely in obs font. [174:19-20] Swapped order of rhs productions for , and put the one into obsolescent font. [464:16+] Added label DO statements to the list of obsolescent features! [465:26+] In the heading, "DO Statement" -> "DO statement"; moved the comma after "purpose" to after "iteration)", "Further" -> "Furthermore". 13-310r3. No changes. 13-327r3. [102:34] "of entities" -> "of the identifiers of entities". EXTRA EDITS: [102:34-35] "that applies to all potentially accessible identifiers in the \si{specification-part} of the module" -> "of the identifiers of entities declared in the module, and of entities accessed from a module whose name does not appear in any \si{access-stmt} in the module". {Remove potential conflict between the previous second sentence and the newly-introduced sentence.} Insert "If an identifier is accessed from another module and also declared locally, it has the default accessibility of a locally declared identifier." {This can happen for a generic identifier in the local scope that is the same as an imported generic identifier or type name, for example.} 13-311r2. No change, but since this action (giving ASYNCHRONOUS or VOLATILE with a BLOCK construct to an entity accessed from outside the construct) can only be done by an ASYNCHRONOUS or VOLATILE statement, I wonder if the description of these semantics more properly belongs in the subclauses for the statements rather than the subclauses for the attributes. /JATA: we prefer these descriptions be in the statements, not in the attributes. Edits are proposed in a new paper. 13-316r2. [463:41+] After "deleted", deleted "from \thisstd{}" {context is talking precisely about this standard vs. previous}, added full stop after "(1) Arithmetic IF statement" {like the others}, "IEEE 754" -> "\theIEEEstd" (currently "IEC 60559:1989") {it is a normative reference}, "; Statement" -> "; statement" {grammar}. 13-322r1. [intro] "BLOCK DATA" -> "block data" {we never uppercase this elsewhere}. [5:35-36] Also set the heading (term) in obsolescent font, but the section number remains in normal font. Is this right? [5:38-39] Ditto. While I was struggline with a LaTeX internal error (actually in the hyperref package as it turned out), I read some of the surrounding text and have some suggestions: SUGGESTED EXTRA EDITS: [30:28-29] "data objects accessible to it" -> "accessible data objects". {Would remove the trailing "it" on the next line.} [31:4] Delete "A scoping unit in another program unit may access the definitions in a module." {We already said in the first sentence that modules make definitions available to other program units! Anyway, the final sentence "Modules are further described in Clause 11." is sufficient.} ACTION: Review and consider doing these edits (I managed to work around the bug by another means). /JATA: yes, we agree with these changes. Edits are proposed in a new paper. [31:18+3] Also obs font for "or" before "BLOCK DATA". [32:15] Also obs font for "and" before "end-block-data-stmt". [101:6] Did not do obs font for "a". [455:4-10] This text already got deleted, so I did what I imagine to be the corresponding edit to the new text. Note that the assertion in the paper that this only happens via obsolete storage association or ENTRY is incorrect; some parts of this happen for sequence association (character) and the %RE and %IM parts of a complex entity. ACTION: Review - did I get this right? For that matter, is the change done by the interp right? (I don't think it is...) /JATA: ??? F03/0124 [12-007 455:4-10] vs [14-007 461:38-41] EXTRA EDIT: [464:16+] Add entry to the obsolescent list. [465:26+] "COMMON"->"Common", "MODULEs"->"modules", "BLOCK DATA"->"The block data program unit". 13-323r1. [intro] Reworded to avoid disparagement. [others] Did not do any of the renaming edits that way. I just did a global replace of forall-header, forall-triplet, forall-limit and forall-step with concurrent-*. I have no idea and no interest in whether the renaming edits were complete or accurate. [4:38] Also deleted "a" which seems out of place. BUT why is not a branch target statement? Surely some mistake. ACTION: Fix. [139:7] Also obs font for ", or the \si{concurrent-limit}s and \si{concurrent-step}s in" since these are also part of talking about the FORALL. Ok, got to [176:21]. This paper is completely unacceptable - it forgot to move the semantics at [164:26] into c08, and it deliberately left the semantics of DO CONCURRENT index variables behind in 7.2.4.2.2 and 7.2.4.2.3 ... after making those subclauses obsolescent! Well, they cannot be obsolescent if they are providing the semantics for DO CONCURRENT! Those subclauses need to be moved into 8.1.6.6 I should think. You cannot be serious about leaving them in the middle of FORALL. No way. Also when this is redone I suggest just saying "global replace forall-step by concurrent-step" (since that is the only thing I will do). Furthermore, all the edits that are not global MUST be in page and line order, not higglety-pigglety. [313:9+] Needs rewording since an assignment statement is not a construct as such, and it is unnecessarily repetitive. I suggest the simpler "safe to reference in constructs such as DO CONCURRENT \obs{and FORALL}". FAILED PAPER 13-323r1. /JATA: ??? 13-317r2. [intro] Did "The nonblock DO construct has been deleted." instead. (There is only one "form".) EXTRA EDITS: [169:12] Deleted 8.1.1p2 since it is no longer true. [169:16-17] Deleted ";however ... (8.1.2)". [175:1-2] Deleted "block-" twice. [175:34,36] "block DO" -> "DO", twice. [177:16] Deleted "block". [187:4-6] Deleted all the articles except the first (they were being used inconsistently anyway). [483:25] "block DO" -> "DO". 13-319r1. [98:4] Also set in obs font "or both", since it can hardly be both generic and specific without obsolescently being specific. [465:26+] "Specific Names of Intrinsic Procedures" ->"Specific names for intrinsic functions", after "The specific names" inserted "of the intrinsic functions". EXTRA EDITS: [287:24-25] Set in obs font "If \si{name} denotes an intrinsic procedure it shall be one that is listed in Table 13.something.". [298:4-5] Set in obs font "and an elemental intrinsic actual procedure may be associated with a dummy procedure (which cannot be elemental)", since this is only for the specific names. [464:16+] Add item to the list of obsolescent features. 13-351r2. [intro] "D, E, EN, ES edit" -> "The D, E, EN, and ES edit", "F descriptor" -> "F edit descriptor". [247:18] Inserted before rather than after (then the floating-point ones are in alphabetic order). [251:22] Ditto (for the same reason). 13-312r4. No changes. 13-329r2. [382:2+] "two arguments" -> "two scalar arguments", "same type and kind type parameter" -> "same type and type parameters", inserted "[, IDENTITY = IDENTITY]" after first "OPERATION" in Case (i) of the Result Value, inserted "[, IDENTITY = IDENTITY]" after "= MASK" in Case (ii) of the Result Value, inserted ", IDENTITY = IDENTITY" after each "= MASK" in Case (ii) of the Result Value. 2.3 Corrigendum 3 ================= [88:14] Moved the edited constraint to [88:13+]. Inserted the new constraint at [88:14+] Inserted at [99:15+] instead. [107:12+] "or have the same rank" -> "or have the same shape". [150:24] ", that is not an optional dummy argument," -> "that is not an optional dummy argument, and". [158:18+,19,20+] These changes have introduced a syntactic ambiguity, there are at least two ways to fix it, therefore added ACTION: ***Unresolved Technical Issue 001***. [170:23+] Omitted "The" for consistency with neighbouring constraints. However, this only forbids the selector expression from being a reference to a funcion that returns a procedure pointer, while still allowing a plain designator to be a procedure pointer. That seems ... wrong. Added ACTION: ***Unresolved Technical Issue 002***. [252:33-34] The replacement text was redundant ("filled with asterisks" twice) and potentially confusingly ordered, so I rewrote and reordered it. ACTION: Review. /JATA: 14-007 [254:32-39] looks ok [309:23,25] Moot as this was rewritten by 13-008r1 (heavily modified). [310:2,3] Said to delete the second sentence (after editing it!) so I deleted the third sentence instead. [431:6] Changed plural to singular. [449:3,4] I did this as per the corrigendum, but after this the relationships exist among "variables, common blocks, and function results that are variables" which can be simplied to "variables and common blocks". ACTION: Review. I recommend simplifification. /JATA: we agree that a simplification is needed. Edits are proposed in a new paper. [459:17+] I did this as it said, but in point of fact the exit status is only *recommended* by the standard, which means that the actual value is *ALWAYS* processor dependent. Furthermore, the processor is not required to support the concept, and this is also therefore processor dependent. ACTION: Review. This should almost certainly say "whether the processor supports a concept of process exit status, and if so, the process exit status on program termination;". /JATA: yes, change [14-007 465:18-19] from: "the recommended process exit status when error termination is initiated other than by an ERROR STOP statement with an integer stop-code (2.3.5);" to: "whether the processor supports a concept of process exit status, and if so, the process exit status on program termination (2.3.5);" $$SW$$ add to paper - ref will be 2.3.6 after 2.4 Last paper from meeting 202 =============================== 13-349r1. [throughout] I did not index "error termination" within Annex A, as (in theory) this is only repeating stuff elsewhere. It is trivial to change this (\linked -> \linkedmindex). ACTION: Tell me if you want this indexed in Annex A. I linked "terminates" to error termination (once in Annex A), "terminates execution" ditto (once in c09). /JATA: yes, these should be indexed. Edits are proposed in a new paper. COMMENT: Maybe "Error termination" should be a separate subclause for easier referencing instead of buried in "Execution sequence"? /JATA: yes, add new setion header "2.3.6 Termination of Execution". [186:4] I did this, but I wonder if instead there should be a blanket rule that "if the of a construct appears on a statement, that statement shall be the statement that begins that construct, ends that construct, or shall be within that construct"? /JATA: yes, CYCLE should be made consistent with EXIT. Edits are proposed in a new paper. [468:27] Also ",ONLY ::" -> ", ONLY:". EXTRA EDIT: In "ENTRY statement", I dehyphenated "type-declaration statement". (This was not the syntax term.) ===END===