J3/14-117r1 To: J3 From: Malcolm Cohen & Van Snyder Subject: Editorial changes and technical fixes Date: 2014 February 11 0. Disposition by /JATA /JATA mostly agrees with the positions in this paper. Look for /JATA below to find comments other than "we agree." Edits are in paper 14-121. One edit proposes additional new semantics for the WAIT statement. 1. Introduction This paper contains suggested editorial changes and technical fixes to 14-007. Sections 2 and 3 list and discuss the editorial and technical issues. Section 4 contains edits to address those items. Section 5 is requesting subgroup and/or committee feedback before trying to address an editorial issue. (Individual edits are not required to fix this, global edits or licence would be better ... once direction is established.) Finally, section 6 is asking a technical question that perhaps should be dealt with via a technical fix (for F2015) or an interpretation request. 2. Editorial changes (some of which are fixes) (a) "An \termi{allocatable} object that is allocated in more than one iteration shall be subsequently deallocated during the same iteration in which it was allocated." has number disagreement "more than one iteration" vs. "the same iteration". This needs rewording. There is also the question that if an object is allocated more than once in an iteration, which allocation does the deallocation need to come after? Obviously there needs to be a deallocation for every allocation, but it might be better to say it should end that iteration with an allocation status of deallocated? But only if those words are clearer than merely fixing the existing words. NOTE: This is the ALTERNATIVE FIX in the edits below. (b) "9.5.6.14 POSITION= specifier in the OPEN statement ... ASIS leaves the position unspecified if the file exists but is not connected. ..." "Not specified" means the standard does not establish an interpretation and that therefore such a program would not be conforming. This is certainly not what we intended! This should say "processor dependent" and be noted in Annex A. I am classifying this as editorial since it is plainly obvious we did not actually mean what the words say. But it is a fix, not a mere "change". (c) "...if that scoping unit contains a module subprogram, internal subprogram, or statement function that defines a procedure ..." should say "statement function statement" since it is talking about the syntax....i.e. the statement function ***IS*** the procedure, it is the statement function statement that defines it. /JATA===================================================================== There is a similar problem concerning instances of subprograms. The rules about duplicate global names prohibit more than one instance of a subprogram. The terminology and subclause heading should be "instances of procedures" or "instances of procedures defined by subprograms." This is discussed in 12.6.2.4 on page 312 in 14-007, but the term "instance of a subprogram" appears in several additional places: [454:34] [455:1] [455:8] [462:3] Should we change these to "instance of a procedure"? /JATA===================================================================== (d) "If a procedure-name appears in the end-mp-subprogram-stmt, it shall be identical to the procedure-name in the MODULE PROCEDURE statement." should say "... in the mp-subprogram-stmt" i.e. use all syntax terms, especially to avoid confusion with those familiar with F90/95 where the MODULE PROCEDURE statement was a horse of a different colour. (e) "A defined input/output procedure may use a FORMAT with a DT edit descriptor", in this, "FORMAT" should be "format specification", since it might be a character format-spec. (f) List of statements that "may" (sic) perform "wait operations" is different in "Wait operation" and "WAIT statement". Also "may" should be one of "do", "can", or "might", depending on whether we want to express actuality, capability, or possibility. 9.7.1 "Wait operation" says WAIT, INQUIRE, FLUSH, CLOSE, data transfer, or file positioning NOTE 9.5.1 in 9.7.2 "WAIT statement" (on the very same page!) says CLOSE, INQUIRE and file positioning Looking at the text for FLUSH, it is the note that is defective and therefore we can fix this by deleting the unnecesarily redundant and misleading note. It would also be nice to put the list in sort-of alphabetic order, at least for the named statements. Also, it might (or might not) be better either to put the whole list into alphabetic order, or to do that while changing "data transfer" and "file positioning" into the statements they actually refer to. NOTE: See ALTERNATIVE CHANGE and SECOND ALTERNATIVE CHANGE edits below. (g) In "Statement functions", "Each dummy argument has the same type and type parameters as the entity of the same name in the scoping unit containing the statement function." after "statement function" insert "statement", since a scoping unit is a piece of syntax and therefore cannot contain a procedure (but can contain a statement or definition). NB: Although "statement function definition" would also be acceptable, since it is a statement I would prefer to have this uniformly referred to as such and indexed as such. (h) List of statements that "may refer to a file that does not exist" should be alphabetic. Also "also may refer" would be better as "is permitted to refer" to make it easier to understand. I hope the prohibitions on statements not on this list from referring to nonexistent files appear elsewhere (not checked!). IF there is no prohibition elsewhere, we probably need an extra edit, e.g. inserting after the text in question "No other statement shall refer to a file that does not exist.". /JATA===================================================================== We could not find such a prohibition. An edit is provided in the separate paper to address this. /JATA===================================================================== (i) The current wording of C533 is slightly defective, as it does not clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as how that does indeed declare "the array bounds of a dummy data object". C533 should probably be reworded similarly to C534a. /JATA===================================================================== F08/0086 appears to address this problem. C535 in 14-007 appears to work correctly. C533 now refers to , not . No edits appear to be needed. /JATA===================================================================== 3. Technical fixes These are numbered not lettered, for uniqueness. (1) "Reinhold has pointed out a problem with the Corr 2 edits to MOVE_ALLOC. We failed to make this edit: [372:24] 13.7.118 MOVE_ALLOC, para 4, after "array bounds," add "array cobounds,"." Those words don't work. Proposed edit has different words. (2) Apparently, "CODIMENSION X[*]" in an inner scoping unit does not block host association so refers to the entity in the outer scoping unit. We obviously did NOT mean that: when we do mean that we always make an explicit statement of the semantics, so this is an obvious oversight. 10-007r1[444+9+] In 16.5.1.4 Host association, para 2, add item to list: (5a) a coarray-name in a codimension-stmt, Those edits work, but I marginally prefer codimension to precede dimension rather than follow it (the rest of the list is not in any particular order so it is not a big deal though). Technically this would appear to be an incompatibility with F2008, however since we do not explicitly state the semantics of a CODIMENSION statement that does not block host association, unlike the situation with ASYNCHRONOUS and VOLATILE, we can weasel that it is not really incompatible. If the weaselling is not considered sufficient we need an edit in Clause 1 to note the incompatibility. 4. Edits to 14-007 [98:8-9] 5.3.8.5 Assumed-size array, C533, replace "An shall not appear except as the declaration of the array bounds of" with "An object whose array bounds are specified by an shall be". {EDITORIAL FIX (i).} [179:28] 8.1.6.6 Restrictions on DO CONCURRENT constructs, p1, bullet item "An allocatable object...", after "shall be subsequently deallocated during" change "the same iteration" to "each iteration". {EDITORIAL FIX (a).} ALTERNATIVE FIX: Replace entire first sentence with "If an allocatable object is allocated in more than one iteration, it shall have an allocation status of deallocated at the end of every iteration.". [201:3-4] 9.3.2 File existence, p3, change "An INQUIRE ... also may refer" to "A CLOSE, ENDFILE, FLUSH, INQUIRE, OPEN, PRINT, REWIND, or WRITE statement is permitted to refer". {EDITORIAL CHANGE (h).} /JATA===================================================================== An edit in a separate paper prohibits other statements from referring to files that do not exist. WAIT is allowed to refer to a unit that does not exist, while FLUSH is allowed to refer to a unit that is connected to a file that does not exist. We cannot think of a reason that WAIT should be allowed to refer to a unit that does not exist, but not to a unit that is connected to a file that does not exist. We propose that this be allowed. This is new. There should be an explicit prohibition against other statements referring to files that do not exist. There should also be an explicit prohibition at [14-007:207:21-22] against statements not in the list referring to units that do not exist. Edits are provided in paper 14-121. /JATA===================================================================== [211:36-38] 9.5.6.14 POSITION= specifier in the OPEN statement, change sentence "ASIS leaves ... not connected." to "If the file exists but is not connected, the position resulting from ASIS is processor-dependent.". {EDITORIAL FIX (b), part 1.} [229:13] 9.6.4.8.3 Defined input/output procedures, p24, between "procedure may use a" and "with a DT edit descriptor", change "FORMAT" to "format specification". Also hyperlink "DT edit descriptor" to "10.7.6 User-defined derived-type editing". {EDITORIAL FIX (e).} [232:15-16] 9.7.1 Wait operation, p1, "WAIT, INQUIRE, FLUSH, CLOSE," -> "CLOSE, FLUSH, INQUIRE, WAIT,". {EDITORIAL CHANGE (a), part 1.} ALTERNATIVE CHANGE: "WAIT, INQUIRE, FLUSH, CLOSE, data transfer, or file positioning" -> "CLOSE, data transfer, file positioning, FLUSH, INQUIRE, or WAIT" SECOND ALTERNATIVE CHANGE: "WAIT, INQUIRE, FLUSH, CLOSE, data transfer, or file positioning" -> "BACKSPACE, CLOSE, ENDFILE, FLUSH, INQUIRE, PRINT, READ, REWIND, WAIT, or WRITE". [232:29+1-2] 9.7.2 WAIT statement, NOTE 9.51, delete entire NOTE. {EDITORIAL FIX (a).} [306:26] 12.5.5.1 Establishment of procedure names, p3, item (1), between "statement function" and "that defines a procedure" insert "statement". {EDITORIAL FIX (c).} /JATA===================================================================== Make sure to insert in \obs font. /JATA===================================================================== [312:30] 12.6.2.5 Separate module procedures, C1269, "the MODULE PROCEDURE statement" -> "the ". {EDITORIAL CHANGE (d).} [315:15] 12.6.4 Statement function, p3, between "containing the statement function" and "." insert "statement". {EDITORIAL FIX (g).} /JATA===================================================================== Make sure to insert in \obs font. /JATA===================================================================== [376:8] 13.7.118 MOVE_ALLOC, p4, "array bounds," -> "bounds, cobounds,", and hyperlink "type parameters", "bounds", and "cobounds" to the defined term. {TECHNICAL FIX (1).} [450:20+] 16.5.1.4 Host association, p2, after list item (4) which ends "", insert new item "(4a) a in a ,". {TECHNICAL FIX (2).} [467:24+] A.2 Processor Dependencies, before bullet item "the default value for the RECL=" insert new bullet item "the position of a file after executing an OPEN statment with a POSITION= specifer of ASIS, when the file previously existed but was not connected (9.5.6.14);". {EDITORIAL FIX (b), part 2. 9.5.6.14 is "POSITION= specifier in the OPEN statement".} 5. Terminological consistency We variously refer to a data transfer statement as "input/output statements" "input statement" "output statement" "data transfer statement" "data transfer input statement" "data transfer output statement" "data transfer input/output statement" "READ statement" and probably many others. Also "input/output statements" is sometimes used to mean "all i/o-related statements including OPEN etc" and sometimes used to mean only "data transfer statements". I am sympathetic to "input" and "output" when only talking about READ or WRITE/PRINT, but the variety is not helpful either for the reader or indeed for indexing. We should reduce this number, preferably to three versions, perhaps "input statement" when talking about input only "output statement" when talking about output only "data transfer statement" when talking about input and output and everywhere "input statement" appears it should be indexed as "data transfer statement", ditto "output statement". And "input/output statements" can still be used when it means all i/o statements. As it is, I did not index "input statement" or "output statement" at all. This really does need to be fixed once we decide what terminology we will use. /JATA===================================================================== We are sympathetic to this view, but have not developed edits. /JATA===================================================================== 6. Technical question I wondered why we did not just say that any i/o statement could perform a wait operation. Apparently an OPEN statement cannot perform a wait operation. Even an OPEN statement changing one of the changeable modes of the connection? It seems unlikely it could do that without waiting for pending asynchronous data transfer operations to complete, /JATA===================================================================== An OPEN statement for a file connected to the specified unit should do a WAIT operation. Edits are provided in paper 14-121. /JATA===================================================================== And since an OPEN statement for a different file will CLOSE the current connection, presumably that will do a wait operation and therefore might return an IOSTAT= value corresponding to the operation being waited on rather than the CLOSE as such? /JATA===================================================================== An OPEN statement for a connected unit that specifies a file different from the file currently file is explicitly specified by 9.5.6.1p4 to perform a CLOSE operation as if by execution of a CLOSE statement. A CLOSE statement explicitly performs a WAIT operation. No edits are required concerning the WAIT operation. It is not clear whether the OPEN statement is considered to have failed to execute if the CLOSE operation encounters an error condition, an IOSTAT specifier appears, and then the OPEN operation appears. If the OPEN statement is considered to have failed in this case, the IOSTAT and ERMSG variable values should be set as if by a CLOSE statement. If the OPEN statement is considered to have succeeded, the IOSTAT variable should be set as specified for an OPEN statement, and the ERMSG variable should not be changed. Edits, if any, await J3 consensus. /JATA===================================================================== Does this deserve a quick technical fix or an interpretation? ===END===