From owner-sc22wg5@dkuug.dk Fri Oct 3 13:00:19 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id h93B0JRA032661 for sc22wg5-domo; Fri, 3 Oct 2003 13:00:19 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from inf.rl.ac.uk (nfs7.inf.rl.ac.uk [130.246.72.7]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id h93B074w032656 for ; Fri, 3 Oct 2003 13:00:09 +0200 (CEST) (envelope-from j.k.reid@rl.ac.uk) Received: from numerical.cc.rl.ac.uk (numerical [130.246.8.23]) by inf.rl.ac.uk (8.11.6+Sun/8.8.8) with ESMTP id h93B0So00147 for ; Fri, 3 Oct 2003 12:00:28 +0100 (BST) Received: from rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by numerical.cc.rl.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id MAA14637 for ; Fri, 3 Oct 2003 12:09:33 +0100 (BST) Message-ID: <3F7D5A26.1090300@rl.ac.uk> Date: Fri, 03 Oct 2003 12:14:46 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: Informal ballot Content-Type: multipart/mixed; boundary="------------020102010304000900050603" X-Spam-Score: 0 () Sender: owner-sc22wg5@dkuug.dk Precedence: bulk This is a multi-part message in MIME format. --------------020102010304000900050603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Two more votes have just arrived - both were sent before the deadline, but something was wrong with the WG5 email service. I have added them to N1575, but neither asks for edits, so no response from the subgroup is needed. Are there any other votes that have not reached me despite being sent before the deadline? Revised draft N1575 attached. John. --------------020102010304000900050603 Content-Type: text/plain; name="N1575.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1575.txt" ISO/IEC JTC1/SC22/WG5 N1575 (Draft of 3 Oct.) Result of the informal ballot John Reid An informal personal ballot on the draft FCD was held during the month of September 2003. The question was as follows: ........................................................................... Ballot on forwarding N1573 (J3/03-007R1) as the FCD for Fortran 2003. Deadline: 9 a.m. UK time on October 1st. [Choose one of the following] Yes Yes, with the following comments No, for the following reasons Signed ............................................................................ All comments were considered by the subgroup consisting of me, Dan Nagle, Richard Maine, and Van Snyder. Here are the ballots with the responses of this subgroup. Appended is a list of all the edits that the subgroup recommended. 1. Richard Maine Yes, with the following comments Apply the following typographical corrections 1. Add "(cont.)" back into the headers of continued notes as in the previous draft. These were unnintentionally dropped. 2. Remove the forced newpage in 1.7 (end of page 5). It is an artifact of pagination problems in an earlier version. 3. [23:6] Delete '("newline", for example)' This edit passed in 220r2, but accidentally not applied. 4. [59:16] "it is is" -> "it is" 5. [64:5] "(D7:Intrinsic assignment statement)" -> "(7.4.1.2)" 6. [113:2] "allocaated" -> "allocated" 7. [430:27] "paraameters" -> "parameters" 8. [447:22] Insert "::" before "real" (but defer to a more complete fix of the technical content of this example if one is proposed.) Subgroup response: accept all these edits. 2. Van Snyder Yes, with the following comments (comments follow angle brackets and subgroup responses have no angle brackets) > [56:12-13] Reformat R451 so as to avoid the 18.8 pt overrun. This > will simultaneously fix the overrun of the same rule on page 513. Agreed. > [208:23] Append "on any file" after "effect". Accept. > [209:22] Append "on any file" after the first "effect". Accept. > In correspondence before meeting 165, Bill Long noticed that there's > no prohibition against deallocating an allocatable , or > changing the pointer association status of a pointer , > inside a SELECT TYPE or ASSOCIATE construct (8.1.4-5). > > I realize it's late -- maybe too late -- to do anything, but if we do > nothing now, we're almost certain to need to process an interpretation > request later. > > There are two possibilities. One is to prohibit these things in > 8.1.4-5. The other is to say something in 16.4.2.1.3 and 16.5.6. > If we do anything, I prefer the former. We suggest that J3 considers this at its next meeting and perhaps submits a suggested change as part of the US ballot. > > [144:9] "data" => "dynamic" Accept. > [144:17] Insert "or a type with the BIND attribute" after "sequence > derived type" (to handle the case allowed by C717). Accept. 3. John Reid Yes, with the following comments [177:18] Change 'a the' to 'a'. [203:NOTE 9.49] In CLASS statement, delete space ahead of comma. [204:NOTE 9.50] In CLASS statement, delete space ahead of comma. [255:35] Change 'entity' to 'identifier'. [430:20] After 'entity' add 'with an identifier'. [The glossary entry was not updated when 16.1 was revised.] [448:1,7,13]. Change 'CLASS' to 'TYPE'. [This is the first of the fixes suggested by Malcolm and was favoured by Aleksandar. I think it is adequate since there is no discussion of overriding in the text of this subsection.] [564:1-3]. Merge the two index entries for . Subgroup response: accept all these edits. 4. More from Van Snyder [78:3] Second "or" => "and" (03-226 part 2). Subgroup response: accept [84:6] "a" => "the" (03-192r1). John Reid thinks a better edit would be "a" => "its" and final "the" => "its". Subgroup response: accept the alternative from John. [180:6] "which" => "that" (03-220r1). Subgroup response: accept [430:27] "paraameters" => "parameters", insert a comma after "components" (03-240). The first change is already in N1575. Subgroup response: accept the second change. [380:34] Insert "support" before "is" (03-214r2). Subgroup response: accept [370:2] "denormalized" => "denormal" (03-214r2). This is, however, inconsistent with 14.10.24. Subgroup response: make no change for the reason given. [43:20+2] "conversions" => "conversion" (03-214r2). Subgroup response: accept 5. Jeanne T. Martin Yes, but please incorporate as many of the things people turn up as possible. 6. Dick Hendrickson Yes, with the following comments 1) The Rule extraction for Annex D is flawed. Rules which are out-of-order in chapter 2 and 3 are not completely skipped. It appears that the 1st line of the rule is correctly not put in the Annex, but following "or" parts of the skipped rule are not skipped. R211 and R307 are examples. Subgroup response: accept 2) Some statements are missing from the "statements" part of the Index. "Program", "Module", "Subroutine" and "Module Procedure" were listed in F95, but are not in the current draft. Also, some of the new F2003 statements are also not listed. I propose adding the following list or a smaller subset of the list. I don't think it worthwhile to add all -stmt forms, things like the END SUBROUTINE statement are just not interesting. action 11:6 ASSOCIATE 160:6 BLOCK DATA 253:8 declaration 10:7 derived type 45:2 ENUM 65:20 executable 10:52 IMPORT 258:36 INTERFACE 258:13 MODULE PROCEDURE 258:27 MODULE 250:7 PROCEDURE DECLARATION 264:6 PROCEDURE 258:27 PROGRAM 249:9 SELECT TYPE 162:6 SEQUENCE 46:12 specification 10:33 statement-function 285:10 SUBROUTINE 282:3 type parameter definition 48:2 USE 251:16 WAIT 206:4 Subgroup response: do not accept. While the index is not perfect, we feel that it is good enough. The work required to check it for all changes at this level of importance would be significant and we feel that it would be wrong to make these changes without the others. 7. Willi Schoenauer Yes. This is not a comment but only a remark: As a "passive" member of WG5 I observed and admired the work of the active members. This allows me to see HOW Fortran evolves. However, the discussions about details shows for me that Fortran goes farther and farther away from a "popular" language. This makes teaching and application ever more difficult. What I wished for the next revision is to "decomplicate" Fortran instead of further complicate it. 8. More from John Reid 544. The section that starts on page 544 should be labelled 'D.2'. Subgroup response: accept 9. David Muxworthy Yes, with the following comments 1. Can the file-unit-numbers in the ISO_FORTRAN_ENV module take any value, positive or negative? [178:30-32] says "a file-unit-number whose value is nonnegative or equal to one of the named constants INPUT_UNIT, OUTPUT_UNIT, or ERROR_UNIT of the ISO FORTRAN ENV module (13.8.2)". [360:15-17] says "The value of the default integer scalar constant INPUT_UNIT identifies ... [snip]. The value shall not be -1.", and similarly for the other two units. This rather bald description implies that negative values may be used but there is no definition of which values, if any. Further, it apparently arbitrarily prohibits the value -1 without giving a reason. Without knowing the intention I cannot offer an edit. Subgroup response: no edit needed. The named constants are allowed to be negative for consistency with some extensions of Fortran 95, but the value -1 has to be excluded because of its use in the INQUIRE statement, see 213:21. 2. Suggested minor edits: 2.1 [3:12] and [437:34+4] "1539:1997" -> "1539-1:1997". Subgroup response: accept 2.2 [432:27] ":D" -> ": D" Subgroup response: accept 2.3 [436:16] "unsigned" -> "unsigned [type]" since the word is used not infrequently in Fortran in connection with constants. Subgroup response: not accept: no other glossary term is followed by a qualifier in square brackets and the present text makes the context clear. 10. Kurt Hirchert Yes, with the following comments Correct subsection numbering in Annex D. (It should not be the case that both subsections are numbered D.1.) Subgroup response: accept 11. Bill Long Yes, with the following comments [544] The section heading "D.1" should be "D.2". D.1 already appears on [505]. Subgroup response: accept There was some earlier discussion on restrictions on the use of an in associate constructs. Some of the issues involve technical content that we proposed to resolve through the interp process. However, there is one change that I think should go in right away (unless I've just missed it in the current draft). When we introduced pointers we had a means of specifying a memory location through two different names. With and we have also have multiple names for the same memory. In the pointer case we explicitly say that the ability to reference and define using the pointer name is tied to the ability to reference and define the target [83:23-24]. In the associate case, we spell out the connection for definition [161:22-23] but don't have the corresponding words for reference. I'd propose something like the following: [161:23+] If the is a that may not be referenced, the shall not be referenced. I think this covers a couple of important cases. If the is referenced before being defined in the construct, then the needs to be defined before that reference. Also, if the becomes undefined (deallocated, for example) then subsequent references using the are not allowed unless the or is defined in the mean time. Whether we want to prohibit deallocation of the outright is a topic for discussion later. Subgroup response: not accepted. We suggest that J3 considers this at its next meeting and perhaps submits a suggested change as part of the US ballot. 12. Toon Moene Yes [ I've read with interest the comments that have been made by other members of our committee - unfortunately, I haven't found the time to check or better (:-) them, so I'll just vote YES ] 13. Michael Ingrassia Yes, with the following comment 1) This is a large language. During public review the document should be scrutinized to see if there might not be "too many" ways to provide some functionality, and the committee should be open to eliminating or making optional the redundant forms. .............................................................................. List of agreed edits 1. Add "(cont.)" back into the headers of continued notes as in the previous draft. These were unnintentionally dropped. 2. Remove the forced newpage in 1.7 (end of page 5). It is an artifact of pagination problems in an earlier version. 3. [23:6] Delete '("newline", for example)' This edit passed in 220r2, but accidentally not applied. 4. [59:16] "it is is" -> "it is" 5. [64:5] "(D7:Intrinsic assignment statement)" -> "(7.4.1.2)" 6. [113:2] "allocaated" -> "allocated" 7. [430:27] "paraameters" -> "parameters" 8. [447:22] Insert "::" before "real" (but defer to a more complete fix of the technical content of this example if one is proposed.) 9. [56:12-13] Reformat R451 so as to avoid the 18.8 pt overrun. 10. [208:23] Append "on any file" after "effect". 11. [209:22] Append "on any file" after the first "effect". 12. [144:9] "data" => "dynamic" 13. [144:17] Insert "or a type with the BIND attribute" after "sequence derived type" (to handle the case allowed by C717). 14. [177:18] Change 'a the' to 'a'. 15. [203:NOTE 9.49] In CLASS statement, delete space ahead of comma. 16. [204:NOTE 9.50] In CLASS statement, delete space ahead of comma. 17. [255:35] Change 'entity' to 'identifier'. 18. [430:20] After 'entity' add 'with an identifier'. [The glossary entry was not updated when 16.1 was revised.] 19. [448:1,7,13]. Change 'CLASS' to 'TYPE'. [This is the first of the fixes suggested by Malcolm and was favoured by Aleksandar. I think it is adequate since there is no discussion of overriding in the text of this subsection.] 20. [564:1-3]. Merge the two index entries for . 21. [78:3] Second "or" => "and" (03-226 part 2). 22. [84:6] "a" => "its" and final "the" => "its". 23. [180:6] "which" => "that" (03-220r1). 24. [430:27] insert a comma after "components" 25. [380:34] Insert "support" before "is" (03-214r2). 26. [43:20+2] "conversions" => "conversion" (03-214r2). 27. The Rule extraction for Annex D is flawed. Rules which are out-of-order in chapter 2 and 3 are not completely skipped. It appears that the 1st line of the rule is correctly not put in the Annex, but following "or" parts of the skipped rule are not skipped. R211 and R307 are examples. 28. [544] The section that starts on page 544 should be labelled 'D.2'. 29. [3:12] and [437:34+4] "1539:1997" -> "1539-1:1997". 30. [432:27] ":D" -> ": D" --------------020102010304000900050603--