ISO/IEC JTC1/SC22/WG5 N1896 Result of WG5 letter ballot on draft Corrigendum 1 John Reid N1894 asked this question Please answer the following question "Is N1893, with the references and notes removed, acceptable for submission to SC22 for publication as Corrigendum 1 for Fortran 2008?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. The numbers of answers in each category were: 6 for 1) Yes. (Chen, Moene, Muxworthy, Reid, Snyder, Whitlock) 2 for 2) Yes, but I recommend the following changes (Corbett, Long) 0 for 3) No, for the following reasons. () 1 for 4) Abstain. (Bader) Four late comments from Malcolm Cohen have been added. The ballot passes, subject to the comments being addressed. Here are the responses in detail with the way they were addressed shown in square brackets. _______________________________________________________________________ Robert Corbett I realize that the issues I am raising here should have been raised earlier. I do not expect any changes to be made either now or subsequently as a result of these comments. In the first edit for the Introduction, the form of the proposed sentence differs from the form of the sentences already present in the cited paragraph. The sentence An array or an object with a nonconstant length type parameter can have the VALUE attribute. [Accepted.] is more in line with the existing sentences. In the second edit for the Introduction, the word "may" in the proposed edit should, perhaps, be "can". [Accepted.] In the edits for Subclause 1.6.2, the final sentence of the second new paragraph could be clearer. The alternative sentence This part of ISO/IEC specifies that an INTENT(OUT) argument of a pure subroutine shall not be polymorphic. is clearer, though wordier. [An alternative improvement was adopted, following the Editor's recommendation.] There might be a problem with the edit for Subclause 5.5. If a derived type definition appears in the specification part of a BLOCK construct, the edits provided appear to say that the scope of a data entity implicitly declared in the derived type definition is the BLOCK construct. The BLOCK construct would be the host of the scope that is the derived type definition. [This is a new technical comment and should be addressed by a new interpretation.] _______________________________________________________________________ Bill Long 2) Yes, but I recommend the following changes. Comment 1: This is not a comment on David's work, but rather an observation of something that might have been overlooked. In the edits for [76:10-] para 9 of 4.5.6.3 is moved to the beginning of the subclause. But the Note 4.49, which naturally refers to that paragraph did not get moved. Should it have been moved as well, or put at the end of the subclause as is often done with notes? The Note now seems out of place. [The note has been moved.] Comment 2: Edit citation [246:15] should have been [246:15+]. [Accepted.] Note that neither of these comments needs to be addressed for the Corrigendum to pass. The first concerns the placement of a Note that can easily be addressed in the next revision. The second relates to text that will be deleted before sending to ISO. These are for consideration mainly if other comments require changes. _______________________________________________________________________ Malcolm Cohen (late comments) COMMENT 1: At [178:18+] more than redundant text has been removed, this is not acceptable - there is NO CONTEXT for this statement about records! It is clearly nonsense if we are talking about different files and clearly incorrect if we are talking about a file connected for direct access. We can go back to the version passed by J3 which was "If records are written to a sequential file by more than one iteration, the ordering between records written by different iterations is indeterminate." However, "sequential file" is a term that is not 100% clear (it is not, as far as I can tell with a quick search, used anywhere else in the standard); the correct terminology is "file connected for sequential access". This gives us "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 indeterminate." If we want to wordsmith that to try to remove redundancy, I get "The ordering between records written by different iterations to a file connected for sequential access is indeterminate." Frankly, I think the more wordy version as passed by J3 (but with my terminology correction) is clearer so I would prefer that. [Accepted.] COMMENT 2: Unfortunately interp f08/0037 contains insufficient edits; it introduces a new feature for F2008 that was not present in F2003 and that is not listed in the Introduction as a new feature. We need a new edit to the Introduction, e.g. after the sentence we insert into the "Programs and procedures" bullet "The PROTECTED attribute can be specified by the procedure declaration statement." If inserting this is out of order at this stage, we will want yet another interp. Sigh. [Accepted.] COMMENT 3: (minor formatting) The formatting for the Table 13.1 replacements has unwanted space before some of the right parentheses, in particular for ALL, ANY, NORM2 and PARITY. THIS_IMAGE is ok as is. [Accepted.] COMMENT 4: (minor formatting) In the edits for 13.7.21, there should be a space between the "I" and the "[3]" in both places. (The text being replaced has the space, so this ought to follow that.) It might be reasonably argued that in the next revision we should revise our conventions in c13 to remove some of the excessive spacing... [Accepted.]