From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Dec 24 17:03:59 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 6B358358330; Tue, 24 Dec 2013 17:03:59 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from out.ipsmtp1nec.opaltelecom.net (out.ipsmtp1nec.opaltelecom.net [62.24.202.73]) by www.open-std.org (Postfix) with ESMTP id C73E43582D9 for ; Tue, 24 Dec 2013 17:03:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAD6wuVICYXlN/2dsb2JhbAANTLsMhDeDRywlPRYYAwIBAgFLDQgCtyqVJIV7F447EQGFDQSQM4dklUGBcQ X-IPAS-Result: ApMBAD6wuVICYXlN/2dsb2JhbAANTLsMhDeDRywlPRYYAwIBAgFLDQgCtyqVJIV7F447EQGFDQSQM4dklUGBcQ X-IronPort-AV: E=Sophos;i="4.95,544,1384300800"; d="txt'?scan'208";a="77016111" Received: from host-2-97-121-77.as13285.net (HELO [192.168.1.2]) ([2.97.121.77]) by out.ipsmtp1nec.opaltelecom.net with ESMTP; 24 Dec 2013 16:03:56 +0000 Message-ID: <52B9B06B.7080009@stfc.ac.uk> Date: Tue, 24 Dec 2013 16:03:55 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: WG5 Subject: Draft result of ballot on Corrigendum 3 Content-Type: multipart/mixed; boundary="------------010706020105020903020401" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------010706020105020903020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is a second draft result of the ballot on Corrigendum 3. I have added David's vote (overlooked in first version) and Malcolm has asked to change his vote (to accord with his recent emails). After consulting the Editorial group, my conclusion is that the corrigendum be accepted after Malcolm's changes have been included. This has 8 yes votes and one no vote. David, please will you make these changes and look at the minor changes that people have suggested? Happy Christmas, John. --------------010706020105020903020401 Content-Type: text/plain; charset=windows-1252; name="N2001-2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N2001-2.txt" ISO/IEC JTC1/SC22/WG5 N2001-2 Result of the WG5 letter ballot on draft Corrigendum 3 John Reid N1998 asked this question Please answer the following question "Is N1995, with the references and notes removed, acceptable for submission to SC22 for publication as Corrigendum 3 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. Email discussion led to the conclusion that the edits in F08/0086 were flawed. A revised version was prepared by Malcolm Cohen and is appended to this paper. All votes referenced this paper. The numbers of answers in each category were: 1 for 1) Yes (Corbett). 1 for 2) Yes, but I recommend the following changes (Snyder) 7 for 3) No, for the following reasons (Bader, Cohen, Long, Moene, Muxworthy, Reid, Whitlock) 0 for 4) Abstain The ballot has failed, but six of those who voted "No" said they would change their vote to "Yes" if the corrigendum is revised to accord with the edits in Malcolm's paper, or words to this effect. I have consulted the editorial subgroup, who recommend that the Corrigendum be accepted after Malcolm's changes have been made. This has the approval of 8 of the 9 people voting. I will ask David to make these changes and the minor changes requested in the vote. After the editorial group has checked the revised corrigendum, I will send it to SC22 for publication. Here are the responses in detail: Reinhold Bader I vote yes, provided the corrections for F08/0086 detailed in the latest version of mjc002.txt are applied. _______________________________________________________________________ Malcolm Cohen Yes, provided the edits for f08/f0086 from N1987 are replaced by those from mjc002.txt distributed on 13 December. _______________________________________________________________________ Robert Corbett My vote is 1) yes. The edits for implied-shape arrays, even as modified, are at best complicated and confusing. My complaint is with the edits not with the corresponding interpretation, which I think is correct. I accept that the latest proposed edits are probably the best we shall get for the Corrigendum. I hope we can do better in the next revision of the standard. As I pointed out in my ballots on the interpretations, the same conditions that led to Subclause 7.1.11 apply not only to the function PRESENT, but also to ALLOCATED and ASSOCIATED. I continue to disagree with the edits proposed for Subclause 14.3, but I accept that I lost the vote in committee and on the subsequent ballots. _______________________________________________________________________ Bill Long Minor typos in the citations: [24:14] should be [24:13]; [24:15] should be [24:15-16]. Typo in the actual official text: In the instruction line for the edit at [459:17+] remove the space between "2.3.5" and ")". Reason for No vote: --------------------------- I agree with Malcolm's original comment that Interp f08/0086 should be failed and restarted. I'm not happy with the proposed last-minute text file of changes for these reasons: 1) A main reason for having a vote like this is to agree (or not) on the exact form of the PDF file form of the Corrigendum - this is basically an "FCD" vote. That purpose is subverted here because the proposers of this path have not supplied the PDF form of their replacements. 2) Another goal of a final vote like this is to reflect on whether we have made a technical mistake. The complexity of the changes proposed for f08/0086, and the problems getting them "right" convince me that we chose the wrong answer for the interp. The alternate answer would result in a trivial, single edit in the standard, and would prohibit only code like that in the interp example that is confusing at best and would never be allowed by any reasonable coding style guide. The place to have this discussion is in the process of restarting the interp. I would change my vote to YES if the minor corrections above are made and the edits for f08/0086 are deleted. _______________________________________________________________________ Toon Moene My vote is yes, after Malcolm's revised edits for F08/0086 are included. _______________________________________________________________________ David Muxworthy 2) Yes, provided the edits for f08/f0086 from N1987 are replaced by those from mjc002.txt distributed on 13 December. _______________________________________________________________________ John Reid 3) No, for the following reasons. F08/0086 should be revised to the new version from Malcolm Cohen that is attached. I will change my vote to yes if the corrigendum is changed accordingly or if the edits from F08/0086 are removed. _______________________________________________________________________ Van Snyder Yes, but: In the edit for [94:10] the "i" in "implied-shape-spec" should be italic instead of upright. [96:28] says "The rank of an implied-shape array is the number of s in the ." The syntax term no longer exists. This sentence is not changed by the corrigendum or interp f08/0086. The sentence needs to be changed to something like "The rank of an implied-shape array is the number of asterisks in the ". If this needs to go back through the interp process, my vote must unfortunately be "no". The edit for [158:19-20] only applies to [158:19]. This doesn't matter for the ISO-published corrigendum, which doesn't have [page:line] references. (Later) I approve the revised interpretation. _______________________________________________________________________ Stan Whitlock I vote Yes, provided the edits for f08/f0086 from N1987 are replaced by those from mjc002.txt distributed on 13 December. ---------------------------------------------------------------------- NUMBER: F08/0086 TITLE: Implied-shape and separate PARAMETER statement KEYWORDS: Implied-shape, PARAMETER DEFECT TYPE: Erratum STATUS: Unknown QUESTION: Q1. Consider Program test1 Character(*) a,b(*) Dimension c(*) Parameter (a='123', b=['1','2','3']) Character(*),Parameter :: c = [ '44','55','66' ] Print *,a,b,c End The definition of the assumed-length character named constant A conforms to Fortran 77 to Fortran 2008. However, the definition of the implied-shape named constant B appears not to conform to Fortran 2008, as the standard says in 5.4.11p2 "A named array constant defined by a PARAMETER statement shall have its shape specified in a prior specification statement." On the other hand, the named constant C does not have such a requirement, so its definition would appear to be conforming. This apparent requirement on the named constant B would thus appear to be inconsistent with those on the named constant C, as well as inconsistent with the way that assumed length works, and with the general principle of allowing attributes to be specified either in a single type declaration statement or with separate specification statements. Is the program intended to conform to the Fortran standard? Q2. Consider Subroutine test2(a) Real,Dimension(*) :: a,c Parameter (c = [ 45.6 ]) a(:size(c)) = c End Subroutine The in the type declaration statement is ambiguous; if it is an then the declaration of A as an assumed-size array is erroneous, but if it is an then the declaration of C as an implied-shape array is erroneous. Is this program-unit intended to be standard-conforming? ANSWER: A1. Yes, the program was intended to conform to the Fortran standard. An edit is provided to modify the requirement for prior specification so as to allow this case. A2. Yes, the program is intended to conform to the Fortran standard. An edit is provided to add syntax to permit this unambiguously. EDITS to 10-007r1: [94:10] 5.3.8.1, R515, Change "" to "". {This will be the unambiguous implied-shape syntax.} [94:10+] Insert new production "<> ". {This will be the otherwise-ambiguous syntax.} [95:32] 5.3.8.5p1 Replace sentence "An assumed-size array is declared with an ." with "A dummy argument is declared to be an assumed-size array by an or an ." {Now two ways of declaring assumed size.} [95:33-] Insert new BNF term "R520a <> [ : ] *" [95:33] R521 , after "<>" Replace entire RHS "[ , ]... [ : ] *" with ", " {The unambiguous case has a list of s.} [95:37+] Insert new BNF rules and constraint "R521a <> C534a An object whose array bounds are specified by an shall be a dummy data object or a named constant." {The otherwise-ambiguous case. Note careful wording.} [96:24-25] 5.3.8.6p1 Replace sentence "An implied-shape array is declared... ." with "A named constant is declared to be an implied-shape array with an that is an or an ." {Now two ways of declaring implied shape.} [96:26] R522, Replace right-hand-side (after "<>") "[ : ] *" with ", ". {This is now the unambiguously implied-shape spec.} [96:28] p2, Change "s" -> "s" and "the " -> "its ", making the entire paragraph read: "The rank of an implied-shape array is the number of s in its ." {Change rank determination to accord with new syntax term.} [107:11] 5.4.11p1 "shape" -> "rank". {In the PARAMETER statement, only require the rank to be specified in a prior specification statement.} NOTE for future investigation: 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. SUBMITTED BY: Bill Long HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm Cohen - passed by J3 meeting 13-237 m200 Failed letter ballot 13-235 m200 Revised with straw votes 13-235r1 m200 Passed by J3 meeting 13-262 m201 Passed as amended by J3 letter ballot #28 13-255r1 N1990 m202 Passed by WG5 ballot N1988/n1987 something ???? Revised edits from draft corrigendum ballot ---------------------------------------------------------------------- --------------010706020105020903020401--