J3/14-122 To: J3 From: Stan Whitlock Subject: Edits from 14-106r1 "Editors notes for 14-007" Date: 2014 February 11 Reference: 14-106r1 Items in 14-106r1 that are marked "Edits are proposed in a new paper." are listed here with proposed edits to 14-007. -------------------------------------------------------------------------- [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 -------------------------------------------------------------------------- [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: I assume this is for annex A.2 "Processor Dependencies". 12-007 [178:17-18] turned into 14-007 8.1.6.6 [179:34-35]: "If records are written to a file connected for sequential access by more than one iteration, the ordering between records written by different iterations is processor dependent." This does not appear in 14-007 annex A.2 - it should. EDITS to 14-007: At [466:33+] insert: "the ordering between records written by different iterations of a DO CONCURRENT construct if the records are written to a file connected for sequential access by more than one iteration (8.1.6)" ---------------------------------------------------------------------- [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] This needs further repair. Edits are proposed in a new paper separate from this paper. -------------------------------------------------------------------------- [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. Compare 12-007 [310:15-23] with 14-007 [313:25-33]. EDITS to 14-007: Change [313:29-31] from: "In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear in the expression of a statement function unless the name is also a dummy argument of the statement function, appears in a FUNCTION or SUBROUTINE statement, or appears in an ENTRY statement that precedes the statement function statement." to: "In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear in the expression of a statement function unless the name is also a dummy argument of the statement function, or appears in a FUNCTION, SUBROUTINE, or ENTRY statement that precedes the statement function statement." -------------------------------------------------------------------------- [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 further repair. Edits are proposed in a new paper. EDITS to 14-007: [328:4-6] change from : "A function listed in Table 13.3 is not permitted to be used as an actual argument (12.5.1, C1240), as a target in a procedure pointer assignment statement (7.2.2.2, C733), as an initial target in a procedure declaration statement (12.4.3.6, C1225), or to specify an interface (12.4.3.6, C1221)." to " "A function listed in Table 13.3 is not permitted to be used as an actual argument (12.5.1, C1240), as a target in a procedure pointer assignment statement (7.2.2.2, C733), as an initial target in a procedure declaration statement (12.4.3.6, C1225), to specify an interface (12.4.3.6, C1221), or in many other situations." [328:6+] Add a new UTI to further comprehensify the list ---------------------------------------------------------------------- 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? ACTION: Surely we should use all Fortran syntax or all maths syntax, not mix them up. /JATA: yes, use ".FALSE. here. EDITS to 14-007: [348:1-] in table 13.4, change "false" to '.FALSE." -------------------------------------------------------------------------- [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 to 14-007: [403:30] change "It" to "Therefore it" ---------------------------------------------------------------------- [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. 12-007 [442] is in 16.3.5 "Argument keywords:. EDITS to 14-007: [448] in 16.3.5, add a new UTI to descrie this problem. -------------------------------------------------------------------------- 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. EDITS to 14-007: [32:30-31] Change: "A procedure that is not pure might change the program state by changing the value of data objects or procedure pointers accessible to it." to: "A procedure that is not pure might change the program state by changing the value of accessible data objects or procedure pointers." [33:4] Delete the sentence "A scoping unit in another program unit may access the definitions in a module." -------------------------------------------------------------------------- [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] This needs further repair. Edits are proposed in a new paper separate from this paper. ---------------------------------------------------------------------- [4:38] Also deleted "a" which seems out of place. BUT why is not a branch target statement? Surely some mistake. ACTION: Fix. /JATA: This needs further repair. Edits are proposed in a new paper separate from this one. -------------------------------------------------------------------------- [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: edits to fix all of this are in a paper separate from this one. -------------------------------------------------------------------------- [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: This needs further repair. Edits are proposed in a new paper. EDITS to 14-007: [456:8-9] Change: "Storage sequences are used to describe relationships that exist among variables, common blocks, and function results that are variables." to: "Storage sequences are used to describe relationships that exist among variables and common blocks <\obs>." ---------------------------------------------------------------------- [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: This needs further repair. Edits are proposed in a new paper. EDITS to 14-007: [465:18-19] Change 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);" Note: In the edit for 14-007 [35:21+] below, we create a new section "2.3.6 Termination of Execution". After that edit, the reference above -------------------------------------------------------------------------- 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. ---------------------------------------------------------------------- 13-349r1 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". EDITS to 14-007: [35:21+] Add new setion header "2.3.6 Termination of Execution" to include 14-007 pg 35, paragraphs 3-5. -------------------------------------------------------------------------- [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: we do not believe a blanket rule is needed. CYCLE should be made consistent with EXIT. In 14-007: [187:7-8] C842 If a appears on an EXIT statement, the EXIT statement shall be within that construct; otherwise, it shall be within the range (8.1.6.3) of at least one . [178:22-23] C818 (R822) If a appears, the CYCLE statement shall be within the range of that ; otherwise, it shall be within the range of at least one . EDITS to 14-007: [178:22] add "on a CYCLE statement" after "appears" {for consistency with EXIT} ----------------------------------------------------------------------