From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Oct 26 03:00:54 2012 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 70C5235695B; Fri, 26 Oct 2012 03:00:54 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 3603 seconds by postgrey-1.34 at www5.open-std.org; Fri, 26 Oct 2012 03:00:52 CEST Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by www.open-std.org (Postfix) with ESMTP id 3108E3568F9 for ; Fri, 26 Oct 2012 03:00:49 +0200 (CEST) Received: from [10.0.1.9] ([unknown] [24.9.79.217]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MCH00CZM40S5F20@vms173021.mailsrvcs.net> for sc22wg5@open-std.org; Thu, 25 Oct 2012 19:00:29 -0500 (CDT) From: Dan Nagle Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Subject: reply to a post, apparently in na-digest Date: Thu, 25 Oct 2012 18:00:28 -0600 Message-id: <21F223B2-8ADD-4AE5-9001-BE670EF9068F@verizon.net> Cc: WG5 List , J3 List To: nadigest.editor@gmail.com, Van Snyder , John Reid MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello, I'm Dan Nagle, chair of PL22.3, the domestic US Fortran committee, and John Reid is the convener of WG5, the international Fortran = committee. We have both received several emails lately, apparently in response to a posting from Van Snyder in na-digest. We have composed a reply, I'm pasting it below. I hope it may be posted to the same venue as Van's original post. (If I am mistaken in my surmise that this is an appropriate email address to which to address a reply, I apologize and I hope you may be able to direct me in a better direction.) Reply pasted below: There are two costs involved in adding a feature to the Fortran = Standard.=20 First, there is the cost in effort by the committees - as the language=20= gets bigger in response to requests, so it becomes more difficult to = find all the interactions between the features and avoid ambiguities.=20 Second, and more important, is the cost to compiler vendors in = implementation.=20 Parameterized derived types (PDTs) are one of the last features to be implemented by most compilers, due to the cost of doing so. Compiler suppliers have estimated that units are likely to be more = expensive than PDTs to implement. Fortran 2003 and Fortran 2008 have added many costly-to-implement = features to Fortran. Compilers are struggling to implement them all -- those for which there is great demand and those for which the demand is more modest. Currently, compilers vary widely in their coverage of Fortran 2008. This impedes portability, as many developers will use only the common subset. Thus, the International Fortran committee has decided to allow only very modest new features into the next = revision of the Fortran standard; changes will be limited to the removal of = simple=20 deficiencies in, and discrepancies between, existing facilities.=20 There are several instances where this may be done without too great an = effort. This is, at least in the main part, to allow compiler suppliers time to = implement all of Fortran 2008. Many compilers have not yet completed their implementation of Fortran 2003. The value of further major new = features at this time, is unclear, to say the least. We have heard from Grant Petty that there is a module that accommodates=20= dimensions and units. He says that the web page=20 http://sleet.aos.wisc.edu/~gpetty/wp/?page_id=3D684 describes the work and includes links to the module source and a=20 paper that was published in 2001 in "Software =F1 Practice and = Experience".=20 He says that the module goes significantly beyond what is described in=20= the paper, and it includes not only fractional dimensions but also=20 predefined values of a very large number of physical constants and = units. How about trying this? =20 The standards committees are already committed to creating two Technical Specifications. These are mini standards for features that are=20= deemed to be too important to wait for the next revision of the = standard. The committees promise to add their features, apart from any glitches = found=20 through use. The first extends Interoperability with C, and is about to = be=20 published. Work has started in earnest on the second, which extends=20 Coarrays. There is support for doing this, even if it will consume the committees' resources to define the features, and the compiler suppliers' resources to implement them. Following = publication, of course, the compiler suppliers must implement the features described = by the TSs before applications programmers will see the benefits. Note that the = facilities described are not available by using features of the current standard.=20= If you could join the Fortran standards committee, you could help = relieve its workload. Are you able to do so? You could also advocate your favorite new features, such as engineering units. --=20 Cheers! Dan Nagle