From owner-sc22wg5@open-std.org Fri Dec 2 15:51:41 2005 Return-Path: X-Original-To: sc22wg5-domo2 Delivered-To: sc22wg5-domo2@open-std.org Received: by open-std.org (Postfix, from userid 521) id CF131149A7; Fri, 2 Dec 2005 15:51:41 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mk-ironport-4.mail.uk.tiscali.com (mk-ironport-4.mail.uk.tiscali.com [212.74.114.32]) by open-std.org (Postfix) with ESMTP id 609CD1155D for ; Fri, 2 Dec 2005 15:51:39 +0100 (CET) Received: from mk-smarthost-3.mail.uk.tiscali.com ([212.74.114.39]) by mk-ironport-4.mail.uk.tiscali.com with ESMTP; 02 Dec 2005 14:51:58 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AAAAANPtj0OGDwEBAQEHCgce Received: from 62-64-223-36.dynamic.dial.as9105.com ([62.64.223.36]:49559) by mk-smarthost-3.mail.uk.tiscali.com with esmtp (Exim 4.30) id 1EiCGS-000HWc-7G for sc22wg5@open-std.org; Fri, 02 Dec 2005 14:51:56 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <0B0232E4-0725-4C43-8256-68F88BD9245C@bcs.org.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sc22wg5@open-std.org From: David Muxworthy Subject: Two further UK requirements Date: Fri, 2 Dec 2005 14:30:22 +0000 X-Mailer: Apple Mail (2.746.2) Sender: owner-sc22wg5@open-std.org Precedence: bulk The UK is submitting two minor further requirements for consideration at the February WG5 meeting; one lacks edits but they will be supplied before the meeting. The items will appear in the next version of the WG5 repository. Meanwhile they are appended below to give WG5 members as much notice as possible. David ------------------------------------------------------------------------ ----------- Number: UK-011 Title: Elemental procedures that are not pure Submitted by: UK Status: For Consideration Severity Level: 3/4 References: Basic Functionality: Allow elemental procedures that are not pure. Indeterminacy can be avoided by specifying that these operate in array element order. Rationale: The problem lies in the (excessive) number of user procedures that need to be written to provide elemental functionality in the case where the PURE requirements cannot be met. With 1 argument, the number is 8, with 2 it is 22, with 3 it is 50; and these will rise to 16, 46, 106 with the agreed increase of maximum rank to 15. Having so many versions is not merely tiresome but also harder to maintain and understand. Furthermore, not addressing this problem inhibits portability to processors which support higher rank than the standard-mandated minimum. The existing elemental procedure facility conflates two ideas: (1) multi-processor performance: a PURE procedure can be invoked on each processor at the same time (assuming any runtime support routines such as the memory allocator and internal i/o library are re-entrant). (2) to define functions or operations which operate elementwise on conforming arrays/scalars. Only the second is inherent in the concept of "elemental"; the first is little more than a potential performance enhancement. The requirement on ELEMENTAL procedures of purity is disadvantageous in the following situations: (i) Debugging is made more difficult, because of the impossibility of inserting PRINT statements. (ii) An elemental operation cannot update a global "operation count" variable, so a suite of such procedures cannot be instrumented to do that kind of performance analysis. (iii) A suite of elemental operations cannot write a log file documenting the operations performed (this is similar to item ii). (iv) An example of an application which finds it prohibitively difficult to use elemental procedures is reverse-mode automatic differentiation (because of the need to produce an execution graph for the reverse mode derivative evaluation). (v) Error handling is forced into the model of returning the error state as part of the result, complicating use of the such a function (and perhaps losing error indications as a consequence). Alternative models such as executing a STOP statement or updating a global error indicator are prohibited by the PURE requirements. (vi) Although a global variable can be used to communicate information from a non-PURE procedure to an ELEMENTAL operation, it cannot effectively be used to do so from one PURE procedure to another. This is particularly germane to operators which by their nature have no optional arguments which could be used to convey anciliary information (such as the accuracy required). This proposal solves the problem without introducing very much new syntax. Furthermore, many other cases are evaluated in array element order (e.g. MAXLOC, i/o, ...) so this is a familiar concept. An impure elemental should be allowed in WHERE (the serialisation requirement might impact performance, but there is no semantic difficulty), but not allowed in FORALL (it would be inappropriate in FORALL: there, purity is the requirement, rather than elementalisability). Another problematic case that would be solved by this is the problem of specifying final subroutines for a datatype. In the not unlikely situation of the final subroutine being impure, this avoids the non-portable and tediously wordy explosion of subroutines based on rank. (Indeed, the original proposed version of final subroutines contained an attempt to address this - via "pseudo-elemental" procedure - though this version proved too complicated and unsystematic to make it into F2003. We should address the problem systematically now, before we make it worse.) Detailed Specification: Introduce a new keyword, IMPURE, which is the opposite of PURE. (A plausible alternative keyword would be SERIAL, as in SERIAL ELEMENTAL; but IMPURE seems attractive...) An ELEMENTAL procedure remains PURE by default but may be declared IMPURE. Such a procedure must still satisfy the "elemental" requirements but need not satisfy the "pure" requirements. As before, a non-ELEMENTAL procedure is IMPURE by default but may be declared PURE. For consistency, since an ELEMENTAL procedure may redundantly be declared PURE, allow a non-ELEMENTAL procedure to be redundantly declared IMPURE. [Edits to be added] Estimated Impact: On the standard, pretty minor. On implementations, noticeable but not major. History: ------------------------------------------------------------------------ ----------- Number: UK-012 Title: Recursive I/O Submitted By: UK Status: For Consideration Severity Level : 3 References: Basic Functionality: Allow I/O on other units during execution of an I/O statement Rationale: It is useful to be able to call tracing and diagnostic I/O routines in a subprogram used within an I/O statement. This facility is commonly available in other languages and the present prohibition appears to be an anomaly in the standard. Estimated Impact: Minimal on standard and on processors; no impact on existing programs. Discussion: F77 explicitly prohibited recursive I/O (section 12.11). However with the changes to recursion in Fortran from F90 onwards, and with many Fortran processors and most other languages permitting recursive I/O, it is anomalous that the Fortran standard does not. It is proposed to remove the restriction on I/O to or from other units during execution of an I/O statement. Detailed Specification: [219:10] After "an an external unit" insert "that is identified by another input/output statement being executed" so that the entire paragraph reads: A recursive input/output statement shall not identify an external unit that is identified by another input/output statement being executed except that a child data transfer statement may identify its parent data transfer statement external unit. History: ------------------------------------------------------------------------ -----------