From owner-sc22wg5@dkuug.dk Thu Oct 9 11:30:50 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id h999UoF2013291 for sc22wg5-domo; Thu, 9 Oct 2003 11:30:50 +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 h999UdEt013270 for ; Thu, 9 Oct 2003 11:30:41 +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 h999V4o11093 for ; Thu, 9 Oct 2003 10:31:04 +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 KAA15523 for ; Thu, 9 Oct 2003 10:40:12 +0100 (BST) Message-ID: <3F852E53.8070806@rl.ac.uk> Date: Thu, 09 Oct 2003 10:45:55 +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: Two new papers Content-Type: multipart/mixed; boundary="------------020700080007040409010605" X-Spam-Score: 0 () Sender: owner-sc22wg5@dkuug.dk Precedence: bulk This is a multi-part message in MIME format. --------------020700080007040409010605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit WG5, Here are copies of two papers that I have put on the server: N1575 Result of the informal ballot (Reid) This is the final version. Please discard any drafts you have. It is a record of all the votes and how the subgroup responded. The FCD is now ready and has been forwarded to the ISO secretariat. It will be visible on the J3 server soon. Phew! A special 'thank you' to Richard for all his careful work. N1577 Change proposed to TR 19767 (Snyder & Cohen) The explains more fully the change that J3 approved in a straw vote at its last meeting. It requires the SUBMODULE statement to specify the ancestor module name if the parent is another submodule. This allows the same submodule name to be used in different module trees. I view it as giving submodules global identifiers of the form I see this as a very desirable change, completely in line with the aim of accommodating very large programs. Does anyone object to J3 working on detailed edits for this change at its next meeting and (provided no serious problems are encountered) including it in the draft TR that they construct then? Remember that we hope to progress to PDTR balloting in December. Cheers, John. --------------020700080007040409010605 Content-Type: text/plain; name="N1577.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1577.txt" ISO/IEC JTC1/SC22/WG5 N1577 25 September 2003 To: WG5 From: Van Snyder, Malcolm Cohen Subject: Change proposed to TR 19767 The purpose of technical report 19767 is to address the deficiencies of Fortran to support large programming projects. In a large project it is likely that the names of global entities will conflict. If submodule names are global identifiers, they will contribute to these conflicts. There is, however, very little reason for the name of a submodule to be a global identifier. The submodule cannot be used by the programmer in any way outside of the "submodule tree" headed by its ancestor module, and even there it can only be used in a SUBMODULE statement. Therefore, in order to remove any unnecessary conflicts that would be caused by the name of the submodule being global, it is proposed that it should be local to its ancestor module. The only change this introduces is that for a submodule of a submodule, the programmer must specify the ancestor module name as well as the parent submodule name. There is no change for submodules of modules. To accomodate this, the following modification of the SUBMODULE statement is proposed: SUBMODULE ( [ : ] ) Beyond this syntax change, which affects [7:21] in J3 paper 03-199r1, edits (with respect to 03-007r1) to implement this change are not extensive: [405:19,22] Insert "non-submodule" before "program unit", twice. {Submodule names are not global identifiers.} [406:9] Delete "and". [406:10] Append ", and". [406:10+] insert "(4) If the scoping unit is that of a module, its submodules". This puts submodule names into a local class of their own, so that they do not clash with any other kinds of names, either local or global. (Submodule names only ever appear on a SUBMODULE statement so there is no chance for confusion.) Submodule names are already not accessible via USE or host association, so there is no additional text needed elsewhere. (The descriptions of use and host association list the things that they give access to, and submodules do not appear in these lists). --------------020700080007040409010605 Content-Type: text/plain; name="N1575.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1575.txt" ISO/IEC JTC1/SC22/WG5 N1575 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" --------------020700080007040409010605--