J3/15-104 To: J3 From: Malcolm Cohen Subject: Editor's report for 14-007r3 Date: 2014 December 24 1. Introduction This is the editor's report for applying the papers passed at meeting 205 to the draft revision, together with paper 14-197r2 from meeting 204 which was missed out in 14-007r2. 2. List of papers applied. 14-197r2 14-234 14-236r2 14-243r2 14-246r1 14-247r3 14-249r3 14-257 14-268 14-270r1 14-271r1 I did not do 14-264r1 as that is a Technical Change i.e. new feature (not to mention that there was some controversy over it anyway). 3. Unresolved Technical Issues 4 UTIs were resolved. 2 attempted UTI resolutions were rejected. 1 UTI was not even attempted to be resolved. 1 UTI was added, making a total of 4 unresolved in 15-007. 4. Report 14-197r2: Note references in this paper are to 14-007r1 not the r2. [439:3-6] Wordsmithed. Heavily. Deleted UTI 004; this does not mean there are no technical problems, but the paragraph being complained about now makes sense (I make no judgement as to whether additional techical requirements or specifications might be required). [439:14-19] This does not seem quite right, and it seems to take a lot of changes to describe the situation properly, therefore this edit is rejected and UTI 005 remains. REJECTED edits for UTI 005. [439:20-22] Wordsmithed. Deleted UTI 006. [454:13-15] Singularised, wordsmited "assigned to that object as a target" to "associated with that object", removed first cross-ref (I do not think it necessary), updated ref to C11. Deleted UTI 007. [439:11-12] The sentence this is modifying does not seem to make sense, and even after the modification I cannot work out what it is trying to say. REJECTED edits for UTI 008. [441:7-14] "and function" -> ", and function". ADDITIONAL EDIT... Next sentence, "The types, macros, and functions declared" ->"The definitions and declarations" ("in ISO_Fortran_binding.h"). Deleted UTI 009. [443:8] Additional edit "each macro expands" -> "each macro defined in ISO_Fortran_binding.h expands". 14-234: DONE without modification. 14-236r2. [445:15] "deferred length parameter" -> "deferred type parameter", since that is the term defined in c01. [445:21] Also hyperlinked and indexed "type parameter" and the preceding "data pointer". [446:4+] Inserted "The statements" at the beginning, used "inlinett" not "jalltt" (and inlinepara afterwards) so as not to get extraneous paragraph numbers, indented code sample by 7 spaces, "associates" -> "associate", "specifies" -> "specify". NB: I will probably rewrite this completely later anyway when I get to the next paper that modifies this subclause. 14-257: [445:12+] Terminated sentence with a full stop. New macro \iprocux for hyperlinking intrinsic with different text (different case actually). [446:4++] Left this before the note as per 236r2. Merged the examples and tweaked the text associated with the 236r2 example. 14-243r2: [181:0+18 Note 8.15] said to: Delete "the range of". However, that text does not appear in Note 8.15; therefore, changed "interior of the range" to "interior of the loop". EXTRA EDIT: [179:25] After "A branch occurs within the" delete "range of a". (So that "the DO construct" is left; this item is within the establishment of a particular DO construct that we are talking about.) 14-249r3: [135:29-31 6.7.3.2p12] appended to the sentence in the new note "and thus an implicit synchronization of all images". 14-246r1: [51:7+] In the paragraph following, hyperlinked "intrinsic type" and "derived type". 14-264r1: This is a Technical Change aka new feature, and so goes to WG5. 14-247r3: [64:26 4.5.2.2p2] "Accessibility" -> "The accessibility". EXTRA EDIT: [64:25] "of a type does" -> "of a type name does". {So the two sentences are using the same words to describe the same thing.} NOTE: I find the resultant opening paragraph of this subclause to be somewhat deficient. Perhaps it should actually say straight out that an on the specifies the accessibility of the type name. One might think that was obvious and did not need stating, but can appear in several places in the derived type definition. Then we can fix the words in p2 so that they do not talk about the "type definition [being] private" which is a farrago of nonsense. ACTION: Further wordsmithing required. [244:5-6 9.11.5p1 second list item] I decline to delete the words "from the intrinsic module IOSTAT_FORTRAN_ENV (13.8.2)"; putting in a cross-reference is IMO insufficient. Inserting that cross-ref also happens to result in very bad typesetting, so I did not do that either. This text is fine and correct as is. Fixed the inconsistency by inserting "from the intrinsic module ISO_FORTRAN_ENV" after the refs to IOSTAT_END and IOSTAT_EOR. [329:1-3 13.5p3] (Mostly) REJECTED. It looks like this was forgotten about when the other command line edits were pulled. Instead, removed GET_ENVIRONMENT_VARIABLE from the list. [346:6+] COMPLETELY REVISED. The edit suggests insertion of "Whether the value assigned to TIME depends upon which image invokes the subroutine is processor dependent." but the preceding sentence already says this value is processor dependent anyway, without any restriction on how it might be processor dependent. Not to mention that since there is no such thing as simultaneity, there is no way to argue about the values on different images. The edit also suggests insertion of "Whether the value assigned to TIME is a per-image value or a per-program value is processor dependent." but quite apart from this being still arguably already handled by the blanket "processor dependent" specification, what is a "per-image value"? It's only assigning on one image so it cannot be per-image (that would imply assigning possibly-different values to the variable on each image at once) and cannot be per-program as that would imply assigning the same value to the variable on every image. So instead I inserted the single sentence: "Whether the value assigned is an approximation to the amount of time used by the invoking image, or the amount of time used by the whole program, is processor dependent." which is what I think we were trying to say. [347:40+] We forgot the date; this is separate from the clock. Therefore I rewrote the insertion. I also changed permission "may" to possibility "might". [358:6+] The suggested wording is unacceptable. Rewrote. I presume that we are deliberately requiring that the processor supports environment variables on all images or on none? That seems reasonable to me, but others might differ. [387:8+] "common random number generator" -> "common generator" (It Is Not A Random Number Generator!) "sequences of values" -> "interleaving of values" (The sequences are already pseudorandom and processor dependent, though we don't come right out and say that; the important thing here is that it is the way the assigned values from the sequence are interleaved is p.d..) "to the HARVEST argument" -> "" (We are in the middle of describing it.) "are" -> "is" (It is the singular interleaving that we are saying is p.d..) ACTION: Looking at this, the standard is crying out for "unordered segments" to be indexed. Someone should do that sometime. [400:7] Also changed "is no clock" to "is no clock for the invoking image", thrice. [400:15+] Omitted the first sentence as it sounds like it makes the number of clocks completely arbitrary, which is not the idea. In the second sentence, changed the first "a clock" to "a single clock" to emphasise that we are talking about 0 or 1 clock per image, not simply 0+. [496:35-37] REJECTED - it is premature to edit this until we have decided what we want to say. Except for GET_ENVIRONMENT_VARIABLE... which this paper seems to have forgotten about. EXTRA EDIT (somewhere): say something about "getenv" in the pd list. [496:41-42] REJECTED - resolution of UTI 010 required. [497:1-2] Instead, changed "calls to" -> "values assigned by" (and then moved as instructed). [497:3-4] REJECTED for CPU_TIME (unnecessary detail already sufficiently covered by existing text). Completely rewrote the DATE_AND_TIME entry, REJECTED for SYSTEM_CLOCK (existing text covers it). BTW this paper gave me a lot of trouble - many hours trying to fix the wording, which I hope I mostly got right(!). ACTION: We must try harder to keep topics to one per paper in future. 14-270r1: [253:32-33] "the the" -> "the". [266:3] This edit was specified inconsistently "to the processor" (after "acceptable") appeared only in the restated wording, not in the separate instructions; inserted those words (which is what we intended). [270:24] EXTRA EDIT: deleted the sentence "Each input value following the equals shall then be acceptable to format specifications for the type of the list item in the corresponding position in the expanded sequence, except as noted in this subclause.", as this seems to be covered by the new wording about raising an error condition. ACTION: Check wording and confirm that this is the case. 14-271r1: [indexing "halting mode" and "underflow mode"] Indexed "handling of any exception" in c15 as "halting mode". [hyperlink procedure names] Fixed typo (in F2008!) "IEEE_SET_FLAGS". [error termination] I note that several places, especially in the coarray stuff, refer to "termination of execution" or just "initiated termination", when only normal termination is intended, not error termination. These ought to be improved. Also, "normal termination" ought to be hyperlinked and indexed similarly. ACTION: Do something about this. [539:5-10] "A procedure" -> "Any procedure", as the whole paragraph is talking about defining external procedures. COMMENT: In retrospect this additional final sentence is probably not needed at all. [check keyword indexing] The operators .AND. et al were only indexed at the subclause that defined the semantics; added indexing for the BNF, the precedence table, and the ALL intrinsic, and linked without indexing elsewhere. Indexed .FALSE. (previously unindexed). Noticed that "constant expression" was indexed as "constantexpression" since forever; fixed. Also fixed the indexing of some things under "Symbols" that were not symbols but names. Indexed minus operation as a minus sign instead of a hyphen, but used a code font minus sign in the "Use of operator" column. ACTION: The edit descriptors are indexed under e.g. "edit descriptor!A", but perhaps they should also be indexed under "A edit descriptor"? Unindexed "format descriptor!G". ACTION: Should the "position editing" descriptors be called "position edit descriptors"? Indexed keyword ALL in IMPORT, ALL. Indexed CLASS keyword. Indexed CONCURRENT keyword at the definition only. Indexed DEFAULT keyword as defn only at CASE DEFAULT and CLASS DEFAULT. Indexed DOUBLE PRECISION, also at c03 - the keywords-with-blanks table. Indexed ELEMENTAL more fully (was only partial before). Ditto IMPURE, PURE. Indexed ELSE IF at c03 keyword table. Ditto ELSEWHERE, END ASSOCIATE, END BLOCK, END CRITICAL, END DO, END IF, END INTERFACE, ENDFILE Indexed END BLOCK DATA at bnf defn and c03 keyword table. Ditto END ENUUM, END FORALL, END FUNCTION, END MODULE, END PROCEDURE, END SELECT (the second one), END SUBMODULE, END SUBROUTINE, END TYPE, END WHERE, Added ENUM statement. Ditto ENUMERATOR. Fixed spurious "ID= in INQUIRE" indexing. Did not index IN or INOUT as they are close to INTENT(IN) etc. Indexed MODULE as keyword in procedure-stmt and mp-subprogram-stmt. NAME= specifier indexing added for BIND(C,NAME=...). Indexed NONE as defn in IMPLICIT NONE and IMPORT, NONE. Indexed NON_INTRINSIC as keyword Indexed NOPASS as defn in two places. Indexed PROCEDURE as a keyword in all the statements it occurs in. Indexed READ (FORMATTED) et all, also FORMATTED and UNFORMATTED. Indexed RESULT. Did not index MEMORY in SYNC MEMORY. Indexed THEN keyword at defn. Indexed TYPE keyword at defn. Did not index "IS" in TYPE IS. Indexed WHILE at defn and some refs. Indexed OUTPUT_UNIT and INPUT_UNIT in the dtio section. 14-268: [jlongtable problems] [Table 1.3] inserted "needspace" to force a page break when it is near the bottom of a page. This is not an ideal solution but I expect this table to move anyway so it is not worth spending time on trying to work out why the LaTeX table went wrong. When we get to FCD stage is the time for that kind of typesetting. [Table 10.1] got moved to the next page already, so I am ignoring this. [136:31-32] EXTRA EDIT: Passivated the next sentence too, it now reads "If no such condition occurs, the definition status and value of are unchanged." [197:24-25] Ditto. [244;16] Ditto. EXTRA EDIT: For no particular reason I happened to read B.2 and spooted a spelling error "terminaton", which I fixed. ===END===