From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Dec 4 07:27:15 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 C640B358253; Wed, 4 Dec 2013 07:27:15 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id 8D9B03580DA for ; Wed, 4 Dec 2013 07:27:12 +0100 (CET) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id rB46R7q7097966 for ; Wed, 4 Dec 2013 06:27:10 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <1A39598779444D5FA3CB0444E79A20B9@Maru6> From: "Malcolm Cohen" To: "WG5" References: <20131126013542.D88A93582CC@www.open-std.org><20131126110419.1106A35832A@www.open-std.org><20131129083253.C1BB43580DA@www.open-std.org> <529CFBA4.2020504@cray.com> In-Reply-To: <529CFBA4.2020504@cray.com> Subject: Re: (j3.2006) (SC22WG5.5121) [ukfortran] [ Draft corrigendum 3] Date: Wed, 4 Dec 2013 15:27:09 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E0_01CEF105.4BFA04D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E0_01CEF105.4BFA04D0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit I wrote: > 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. > > 3) No, for the following reasons. > > The edits for F08/0086 do not work. This interp must be failed and restarted, > and the corrigendum must be altered to remove it. Bill Long replied: >I'm happy with this comment. But what is the larger plan? > >1) The rest of the Corrigendum is OK and your vote changes to YES if the >F08/0086 edits are removed and we move forward with what remains, or I have not checked the rest of the corrigendum yet... >2) Fixing the problem raised by F08/0086 is sufficiently important to >put the Corrigendum on hold until it is repaired and put up for another >vote, considering that this is the final Corrigendum for F2008. If we follow the normal "back to square one" procedure, that is a delay until April at the most wildly optimistic (February meeting + J3 letter ballot + WG5 letter ballot). Here is a third alternative: 3) New corrected edits are unanimously agreed by WG5 and J3 during the Corrigendum ballot. A single "No" vote should definitely send this interp back to stage one (but not the rest of the corrigendum). I attach a corrected interp, the differences are: (i) New syntax term "" (I did not like my own suggestion of ""). "assumed-implied" rather than "implied-assumed" because assumed-size arrays are described first. (ii) I "improved" the edit for [95:33] cosmetically, as well as using the new syntax term. (iii) Used the new syntax term in R522, twice. (iv) New edit for [96:28] to use the new syntax term in the rank determination. (v) Removed NOTE (1) and reformatted the remainder. I think this is right this time, but who knows? If anyone is unconvinced that this is right, or is uncomfortable with the idea of such a radical last-minute fix, we should send this back though the system to get a more leisurely review. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_00E0_01CEF105.4BFA04D0 Content-Type: text/plain; format=flowed; name="mjc002.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mjc002.txt" ---------------------------------------------------------------------- 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 ... ." with "A named constant is declared to be an implied-shape array by 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, replace "s" with "s" {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 ---------------------------------------------------------------------- ------=_NextPart_000_00E0_01CEF105.4BFA04D0--