From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Jun 18 23:04:41 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 57E783568CD; Mon, 18 Jun 2012 23:04:41 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1242 seconds by postgrey-1.34 at www5.open-std.org; Mon, 18 Jun 2012 23:04:40 CEST Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by www.open-std.org (Postfix) with ESMTP id 64FC03568B4 for ; Mon, 18 Jun 2012 23:04:39 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5IKhsq2005650 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Mon, 18 Jun 2012 13:43:54 -0700 Subject: Re: (j3.2006) (SC22WG5.4709) UK position paper on revision of Fortran 2008 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <20120618112730.A965A3568CD@www.open-std.org> References: <20120618112730.A965A3568CD@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Mon, 18 Jun 2012 13:43:53 -0700 Message-ID: <1340052233.22973.221.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-24.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Mon, 2012-06-18 at 04:17 -0700, David Muxworthy wrote: > The BSI Fortran panel has produced a paper summarizing our thoughts on > the revision of Fortran 2008. It is attached as WG5-N1923. > David While I understand and sympathize with the BSI view on development of Fortran in the near term, there are a few areas for which my sponsors have been keen to have support for several decades. I and several colleagues were asked by the US Department of Defense to review requirements proposals for a language that was at the time called DoD-1, and later became Ada. In the mid- to late-1970's, at about the strawman stage (certainly no later than tinman), we proposed that Ada, intended to be a high-reliability language, ought to provide support to check and convert units of measurement. Such a requirement was not added. Some time before 1986, we proposed that Fortran 90, intended to be a language to support scientific and engineering computation, ought also to have a system to check and convert units. I proposed this again for the 2008 revision. NASA understands quite well the consequences of not checking units, having lost the Mars Climate Orbiter mission (which cost in excess of $300 million) due to a units error that would have been caught or corrected automatically if the appropriate features had been in place and used. If a change of this magnitude is decided to be out of order during the next several years, there is a good chance that NASA, JPL and Caltech will find little reason to continue to support my participation. I have prepared a proposal for support for a system of units of measurement, in the form of a technical specification. Anybody who is interested is welcome to have the current draft. I had planned to discuss this in Toronto. Length parameters of derived types can be simulated using allocatable components. In many cases, this is what processors would do "under the covers." I wouldn't object to length parameters being deprecated and eventually deleted. Part of their justification was that CHARACTER has a length parameter. But this length parameter is nothing more than a dimension whose subscript appears in row-major order. This was remarked during development of Fortran 77. Had CHARACTER type and Fortran 90 array facilities been developed together, they might have been more consistent. Kind parameters cannot be simulated, except by a complicated kludge involving INCLUDE, multiple modules, and renaming during USE. If any vendors want my opinion about priorities, I put kind type parameters far above length type parameters. Richard Maine pointed out, however, more than a decade ago, that there are significant integration problems between type-bound procedures and kind type parameters. The proposals for generic programming, one based on parameterized modules and one on macros, were meant to address this problem. We ended up with neither of them. A third approach, which I proposed at (and perhaps in correspondence before) the 1986 Albuquerque meeting, was to allow procedures to be defined within type definitions. This integrates well with kind type parameters. It is possible in principle to specify that a procedure has parameters as well as arguments, using a device that might be considered a restricted form of "template." Creating a procedure from a template could be done either by explicitly creating one using something akin to Ada's "new" specification, or implicitly and indirectly by binding to a type that has kind parameters and then instantiating an object of the type. At least one of these four approaches, or something that achieves the same objective, should be on the table for the next revision. I don't object to deprecating defined input/output, since this can be simulated by non-advancing I/O, but only for formatted input/output. If non-advancing I/O were to be extended to unformatted input/output, the functionality of defined input/output would be unnecessary. Having spent several decades developing mathematical software that needs access to user code, using reverse communication, doing battle with the inconsistency of GOTO or ENTRY and canonical control structures, I and my colleagues have been hoping for support for coroutines. One might argue that with type extension the need for coroutines is less urgent. There are two reasons why this is not quite true. First, if a large program uses an existing reverse communication interface to mathematical software, the expense to convert it to use type extension is far greater than continuing to provide reverse communication, in the mathematical software libraries, using the present expensive methods. Second, there are applications beyond those where one code needs access to another. The general principle is that there are benefits from the activation record being retained even though the current sequence of execution is not within the procedure. Further, iterators are essentially coroutines more similar to functions than subroutines, and invoked only by control constructs. I have prepared a proposal for coroutines and iterators in the form of a technical specification. Anybody who is interested is welcome to have the current draft. I had planned to discuss this in Toronto. Methods for block-structured exception handling have been proposed several times (e.g., N1257). The IEEE support modules were intended to address this problem, but do a very poor job of a small subset of it. A block-structured exception handler should be based upon enumeration types and sets of enumerators, not named integer constants. The BIND(C) ENUM feature does not define a new type, but should have done so. Enumerations as true types, not syntactic sugar for named integer constants, interact with subranges of integers, and set types. Those three ought to be considered, if at all, as an integrated collection. Two other topics related to a more complete type system are the creation of new types (not aliases) from existing ones, and elevating section subscript designators to first class. I have prepared a proposal for a more complete type system in the form of a technical specification. Anybody who is interested is welcome to have the current draft. I had planned to discuss this in Toronto. I also have a wide-ranging collection of 112 items, resulting from discussions with colleagues during the last four decades, organized into a 48-page paper. Many of the items in that paper were proposed during the collection of requirements for Fortran 2008. Anybody who is interested is welcome to have the current draft.