From owner-sc22wg5@open-std.org Tue Mar 22 19:56:58 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id DD2D0C178E4; Tue, 22 Mar 2011 19:56:58 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 835 seconds by postgrey-1.18 at www2.open-std.org; Tue, 22 Mar 2011 19:56:57 CET Received: from mk-filter-1-a-1.mail.uk.tiscali.com (mk-filter-1-a-1.mail.tiscali.co.uk [212.74.100.52]) by www2.open-std.org (Postfix) with ESMTP id C1DA4C178DC for ; Tue, 22 Mar 2011 19:56:57 +0100 (CET) X-Trace: 596578131/mk-filter-1.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/88.104.252.31/None/d.muxworthy@bcs.org.uk X-SBRS: None X-RemoteIP: 88.104.252.31 X-IP-MAIL-FROM: d.muxworthy@bcs.org.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Apple Mail (2.753.1) X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcCAFaKiE1YaPwf/2dsb2JhbAAMmDmWO7tIhWgEkDE X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208";a="596578131" Received: from 88-104-252-31.dynamic.dsl.as9105.com (HELO [192.168.1.2]) ([88.104.252.31]) by smtp.tiscali.co.uk with ESMTP; 22 Mar 2011 18:43:00 +0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <20110303174947.DD0CAC3BA01@www2.open-std.org> References: <20110303174947.DD0CAC3BA01@www2.open-std.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CC8DCCE-D33F-444F-B6ED-13A58C3C1735@bcs.org.uk> Content-Transfer-Encoding: 7bit From: David Muxworthy Subject: Re: [ukfortran] (SC22WG5.4408) WG informal ballot Date: Tue, 22 Mar 2011 18:43:53 +0000 To: sc22wg5@open-std.org X-Mailer: Apple Mail (2.753.1) Sender: owner-sc22wg5@open-std.org Precedence: bulk > Please answer the following question "Is N1845 ready for forwarding > to SC22 > as the PDTR?" in one of these ways. > 1) Yes. > 2) Yes, but I recommend the following changes. > 3) No, for the following reasons. > 4) Abstain. No, for the following reasons. 1. Reasons for negative vote 1.1 The document is self-evidently not ready for issue as a PDTR, containing as it does six explicitly unresolved items. 1.2 Given the reservations expressed in N1844 and in subsequent email discussion it appears that significant technical problems remain to be resolved. I would withdraw this objection if paragraph 7 of the Foreword were changed to state that the facilities described in the document were experimental and not necessarily to be incorporated in a future standard[1], or if the project schedule were to be extended to allow further consideration of the proposals. This would also allow for addressing the concerns that implementation costs may be high relative to user benefits and that Fortran is losing some of the (relative) coherence and consistency gained in designing F90/95. See also 5.1 below. [1] The definition of a Technical Specification allows for this. 2. Comments on unresolved technical issues 2.1 UTIs 17 and 18: As a matter of principle any infringement that can be detected at compile time should be a constraint. 2.2 UTI 15: I agree with Malcolm's point. 3. Other comments 3.1 If it is decided in a future revision that Fortran should limit the range of values taken by variables, then '..' would be an obvious delimiter, as it is in Ada and Pascal. The symbol '..' should not be used here unnecessarily. 3.2 I would welcome an assurance that the new language features do not cause hidden interactions with, or unacceptable costs for, existing facilities, independent of interoperability. 4. Minor editorial points 4.1 The document refers to itself as both a TR and a TS. It should choose one. 4.2 References to J3 should of course be removed before submission. 4.3 Subclause A.1.6 uses KIND=4 and KIND=8 without any corresponding description. There should be a comment or the code should be generalized. 5. A contrary view 5.1 The original project specification, N1667, was to extend the functionality of passing Fortran arguments to C. It was not to change the Fortran language to accommodate a wider range of C arguments passed to Fortran or to incorporate further C concepts into Fortran. Clause 5 of this document would look out of place in a Fortran standard. The material would be more appropriate in a stand-alone document for those who need to use these facilities. While certain programming techniques may be common in C, it does not necessarily follow that Fortran should be distorted in order to accommodate them, unless there is very strong user demand. David Muxworthy