From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Aug 6 02:14:04 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 1D23935721A; Tue, 6 Aug 2013 02:14:04 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by www.open-std.org (Postfix) with ESMTP id D1190356920 for ; Tue, 6 Aug 2013 02:13:46 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r760Dh2n030121 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Mon, 5 Aug 2013 17:13:44 -0700 Subject: [Re: WG5 letter ballot 6 on Fortran 2008 interpretations] From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Mon, 05 Aug 2013 17:13:43 -0700 Message-ID: <1375748023.9751.1143.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-30.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk ISO/IEC JTC1/SC22/WG5 N1988 WG5 letter ballot 6 on Fortran 2008 interpretations John Reid, 4 August 2013 This is the sixth WG5 vote on a set of draft interpretations for Fortran 2008. They have all been approved in a J3 letter ballot. The following Fortran 2008 interpretations are being balloted: Yes No Number Title -Y- --- F03/0030 IEEE divide by zero -Y- --- F03/0047 Polymorphic arguments to intrinsic procedures -Y- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -Y- --- F03/0064 Recursive declaration of procedure interfaces -Y- --- F03/0100 Error in field width for special cases of signed INFINITY output --- -N- F03/0139 Functions returning procedure pointers In the edit for [278:11], "... function result if it is a function" seems a bit redundant. Would "... function result" be good enough? If the procedure is a subroutine, it can't have a function result. In the edit for [310:5-6], the term "result names" is used. In other edits, the term "function result" is used instead of simply "result". Should "result names" here be "function result names", for consistency? [310:6-7] appears to imply that a function subprogram cannot define two functions that have procedure pointer results with different characteristics, or some that have procedure pointer results and others that have data object results (because a procedure pointer cannot be storage associated with another one, or with a variable). This ought to be clarified or repaired. If these are considered to be fodder for a different interpretation request, rather than further work necessary for the present one, this mark on my ballot can be changed to "yes with comment." The edit for [170:23+] could more economically combine the requirement with C804: " shall not be a variable or a function reference that returns a procedure pointer." -Y- --- F08/0071 Vector subscript target -Y- --- F08/0075 Pointer function reference as variable in assignment -Y- --- F08/0076 Pointer function reference in READ Subsumed by F07/0075 -Y- --- F08/0083 Type parameter default expressions allow circular dependence -Y- --- F08/0084 Pointer arguments to PURE functions -Y- --- F08/0085 Problems with PARAMETERs -C- --- F08/0086 Implied-shape and separate PARAMETER statement For the archive, in the question, replace "conforms to Fortran 77 to Fortran 2008" with something like "conforms to Fortran 77 through Fortran 2008" or "conforms to all Fortran standards from 2007 to 2008". -Y- --- F08/0087 Mixed-kind character assignment -Y- --- F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? -C- --- F08/0089 Variable-denoting functions change existing semantics The term "pointer function" is not used as a noun, although "nonpointer function" is so used at [454:36]. I have a slight preference that "pointer function" in the edit for [24:11+] be replaced by "function that returns a pointer result" in both paragraphs. The same change ought to be made in the edits for [24:27+] and [25:6+] A parallel change ought to be made at [454:36], but that can be done editorially rather than within this interpretration. --- -N- F08/0090 What restrictions apply to initialization and PARAMETER? One might argue that type, type parameters, and shape are covered by 5.2.3p1. In the examples, the cannot be "converted according to the rules for intrinsic assignment." Since this is impossible, no interpretation is established, and the examples are not conformant, and therefore no edits are needed. On the other hand, the description of the conversion in 5.2.3p1 needs to have some attention to cover the implied-shape case. The text of these interpretations is in N1987. Each interpretation starts there with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send to sc22wg5@open-std.org by 0900 UK time on Monday, 2 September 2013, in order to be counted. Thanks, John.