From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Jun 11 23:36:35 2014 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 23CB7A4ADB6; Wed, 11 Jun 2014 23:36:35 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 605 seconds by postgrey-1.34 at www5.open-std.org; Wed, 11 Jun 2014 23:36:34 CEST Received: from out.ipsmtp2nec.opaltelecom.net (out.ipsmtp2nec.opaltelecom.net [62.24.202.74]) by www.open-std.org (Postfix) with ESMTP id ACBBD358705 for ; Wed, 11 Jun 2014 23:36:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQBAETImFNYaPPf/2dsb2JhbAANTa8GAQEBAQEBBpYKhDCHZLg2oDwXhVyIGwsGAYQCgRYEhVyMGYQvmxKBbQg X-IPAS-Result: ArQBAETImFNYaPPf/2dsb2JhbAANTa8GAQEBAQEBBpYKhDCHZLg2oDwXhVyIGwsGAYQCgRYEhVyMGYQvmxKBbQg X-IronPort-AV: E=Sophos;i="5.01,460,1400022000"; d="txt'?scan'208";a="159387612" Received: from 88-104-243-223.dynamic.dsl.as9105.com (HELO [192.168.1.2]) ([88.104.243.223]) by out.ipsmtp2nec.opaltelecom.net with ESMTP; 11 Jun 2014 22:26:23 +0100 From: David Muxworthy Content-Type: multipart/mixed; boundary="Apple-Mail=_96A638A2-A0D9-42DE-8198-5C60BE3CD062" Subject: UK proposals for WG5 Message-Id: Date: Wed, 11 Jun 2014 22:26:21 +0100 To: sc22wg5@open-std.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Sender: owner-sc22wg5@open-std.org Precedence: bulk --Apple-Mail=_96A638A2-A0D9-42DE-8198-5C60BE3CD062 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Herewith UK proposals for removal of warts, irregularities, etc in F08. David Muxworthy --Apple-Mail=_96A638A2-A0D9-42DE-8198-5C60BE3CD062 Content-Disposition: attachment; filename=N2016.txt Content-Type: text/plain; name="N2016.txt" Content-Transfer-Encoding: quoted-printable ISO/IEC JTC1/SC22/WG5 N2016 UK PROPOSALS FOR REVISION OF FORTRAN 2008 SUBMITTED TO WG5, JUNE 2014 The BSI Fortran panel wishes to submit the following proposals for the revision of Fortran 2008 for consideration by WG5. To avoid possible confusion, they are numbered consecutively from the items in WG5-N1975. They are arranged in order of subclause, not in order of priority. To conform to J3 guidelines, the syntax and specification for each item is in a separate J3 paper. = --------------------------------------------------------------------------= - Number: UK-11 Title: Assumed coshape Status: For Consideration Basic Functionality: =0D Allow a dummy coarray to assume its coshape from the actual argument, =0D= similarly to the way that a dummy (assumed-shape) array can assume its =0D= shape from the actual argument.=0D =0D Rationale: =0D This would be convenient and there seems to be no technical problem =0D with providing such a facility. To get functionality in Fortran 2008 =0D that matches that shown in the example in the edits would require =0D passing the coshape or working exclusively with allocatable coarrays.=0D =0D Specification:=0D Add syntax for "assumed-coshape" that can only be used to declare a =0D dummy argument. A dummy argument so declared assumes the shape =0D (but not necessarily the bounds) of the actual argument. =0D Specification: Allow a dummy coarray to be declared with all codimensions colons to specify the corank. The shape is taken from the effective argument. Syntax and edits: See J3/14-190 = --------------------------------------------------------------------------= - Number: UK-12 Title: File-unit connection Status: For Consideration Basic Functionality: Allow a file to be connected to more than one unit at one time. Rationale: It can be convenient to connect a file to more than one logical unit at one time. Whether or not this is possible is a function of the operating system. It should not be prohibited in the language itself. The programmer can determine whether or not it is possible in particular cases by examining the output from the IOSTAT specifier in the OPEN statement. Specification: Remove the prohibition on a file being connected to more than one unit at one time. Syntax and edits: See J3/14-174 = --------------------------------------------------------------------------= - Number: UK-13 Title: I/O error conditions Status: For Consideration Basic Functionality: Standardize certain I/O error conditions Comment: This proposal refers only to numeric input errors. It could be extended to other I/O errors. Rationale: Standardize certain I/O error conditions so as to allow a=20 standard-conforming program to regain control after an error. Specification: During execution of a formatted READ statement which includes an IOSTAT specifier, if the characters input to a numeric value are not acceptable to the processor, the variable specified in the IOSTAT=3D specifier shall be defined with a processor-dependent positive integer value. Syntax and edits: See J3/14-175 = --------------------------------------------------------------------------= - Number: UK-14 Title: Minimal exponent width Status: For Consideration Basic Functionality: Minor FORMAT extension Comment: This is item 2.1 and part of 2.3 of section UK-04 of N1975. Rationale: Allow a more robust, and usually more compact, form for the printing of numbers in scientific notation, particularly for values with large exponents. A deficiency of the Ew.d descriptor is that the +/-0nn and +/-nnn output forms for exponents can cause silently wrong effects when fed to almost any other language or application. Further Ew.d as currently defined cannot cope with exponents greater than 999 (these can appear e.g. for IEEE 128-bit floating-point numbers). If Ew.dEe is used to force the printing of the exponent letter (E) and to avoid possible exponent overflow, wide variations in values can lead to an unnecessary number of leading zeros in the exponents. Specification: For output using E, EN, ES, or G edit descriptors, add a means to request "minimal exponent width". This will display the whole exponent value without leading zeros (and display a single 0 digit for zero exponent). Syntax and edits: See J3/14-176 = --------------------------------------------------------------------------= - Number: UK-15 Title: GENERIC statement as alternative to interface block Status: For Consideration Comment: This is US-06 from N1982 which was "subject to WG5 review in 2014". The BSI panel endorses this proposal. A somewhat similar proposal was made by Espen Myklebust. The following is copied from J3/13-209 except that page and line references to 14-007r1 have been added (specified subclause numbers have not changed between 10-007r1 and 14-007r1) Basic functionality: Allow a GENERIC statement as an alternative to an interface block, with syntax similar to its use within a type definition. Rationale: Reduces the number of statements, and thereby long-term cost. Estimated impact: Minor Markham M6 conformance: Remove simple deficiency and discrepancy. Detailed specification: Allow a GENERIC statement as an alternative to an interface block, with syntax similar to its use within a type definition. Syntax and edits: See J3/14-177 = --------------------------------------------------------------------------= - Number: UK-16 Title: INTENT(IN) and VALUE Status: For Consideration Basic Functionality: Remove anomaly of INTENT(IN) and VALUE for generic interfaces Rationale: Constraint C1267 for pure procedures in F03 was "The specification-part of a pure subroutine subprogram shall specify the intents of all its nonpointer dummy data objects". In F08 this was changed to (C1277) "The specification-part of a pure subroutine subprogram shall specify the intents of all its nonpointer dummy data objects that do not have the VALUE attribute" but this change was not reflected in the description of generic interfaces. This leads to anomalies such as: PURE SUBROUTINE s(a,b) TYPE(t),INTENT(Out) :: a TYPE(t),VALUE :: b ... END SUBROUTINE is valid in itself, but INTERFACE ASSIGNMENT(=3D) MODULE PROCEDURE s END INTERFACE is not valid with that procedure. Similarly for a pure function that uses VALUE but not INTENT(IN), and OPERATOR(any operator). A similar situation relates to F03 constraint C1266 which was updated to C1276 in F08 so as not to require an intent if VALUE was specified, but C1205 was not updated correspondingly. Specification: Update the definition of arguments in generic interfaces and amend constraint C1205 to align it with C1276 in F08, which is now C1285 in 14-007r1. Syntax and edits: See J3/14-178 = --------------------------------------------------------------------------= - Number: UK-17 Title: Recursion by default Status: For Consideration Basic Functionality: Make RECURSIVE the default for procedures. Rationale: It is annoying for the user to have to specify RECURSIVE for a procedure that can call itself recursively. Other high level languages have had recursion as a default for many years; this is a stumbling block for new users. The trouble with the current situation is that if the compiler produces non-recursion-capable code for a procedure that is not declared to be RECURSIVE (e.g. by storing one or more local variables statically = instead of dynamically), and does not detect invalid recursion, the result is silent wrong answers. All standard-conforming compilers already implement recursion so the new implementation effort required is minimal. The basic form of this proposal only applies to procedures that are permitted to have the RECURSIVE attribute; elemental ones do not at present. The restriction against elemental recursion was intended to = make elemental procedures easier to implement and optimise; this has outlived its purpose, so an alternative set of specs and edits is proposed to = lift that restriction as well. Specification: All nonelemental subprograms should by default have the RECURSIVE attribute. ALTERNATIVE (additionally lifting the elemental recursion prohibition): Specification: [as above with "nonelemental" deleted] Syntax and edits: See J3/14-179 = --------------------------------------------------------------------------= - Number: UK-18 Title: Consistency of intrinsic arguments Status: For Consideration Basic Functionality: Improve consistency of intrinsic arguments Rationale: There is inconsistency amongst arguments to intrinsic functions, especially LOGICAL ones, in that some are required to be of default kind and some are not. When KINDs were first introduced the policy was to allow any kind for input arguments, and default kind for output arguments. Consistency has been lost and should be restored. The BSI panel endorses Stan Whitlock's paper on this subject.=20 Specification: Improve consistency of intrinsic arguments. Syntax and edits: See J3/14-180 = --------------------------------------------------------------------------= - Number: UK-19 Title: COSHAPE intrinsic Status: For Consideration Basic Functionality: Add COSHAPE intrinsic Rationale: It is irregular to have LCOBOUND and UCOBOUND intrinsics, but not to=20 have COSHAPE.=20 Specification: Add COSHAPE intrinsic to return the coshape of a coarray.=20 Syntax and edits: See J3/14-181 = --------------------------------------------------------------------------= - Number: UK-20 Title: Bitwise logical functions Status: For Consideration Basic Functionality: Improve consistency of IAND, IEOR, IOR Rationale: The MAX and MIN functions may take an arbitrary number of arguments. There is no reason to restrict the number of arguments of the bitwise logical functions to two. To remove the limit would allow expressions with multiple logical function references to be easier both to write and to understand. Specification: Edits are required to Table 13.1 and subclauses 13.7.72, 13.7.78, 13.7.82. Other references to these functions need not be altered. Syntax and edits: See J3/14-182 = --------------------------------------------------------------------------= - Number: UK-21 Title: Numeric conversion check Status: For Consideration Basic Functionality: Numeric conversion check Comment: This proposal is a development of UK-07 in N1975. Rationale: It is tedious (and mistake-prone) to check if values of one intrinsic type can be converted to another without error. Specification: Add a new intrinsic function or functions which can check whether a REAL = or INTEGER value can be converted to a different type (or kind) without = error, where "without error" means no integer or real overflow will occur. The function(s) should be able to handle rounded conversions (NINT) when checking for conversion to INTEGER, as well as truncating ones (INT). For conversions between different REAL kinds, an IEEE infinity is not considered to be an error unless it is not representable in the target kind. The conversions to be checked shall be those of: REAL INT NINT The functions AINT and ANINT (with a KIND=3D argument) need not be = handled by the feature, since their use for conversions is not as frequent, and it = is not too onerous to check using AINT/ANINT without KIND=3D. The requirement to be able to handle NINT directly is because this is a common conversion. Syntax and edits: See J3/14-183 = --------------------------------------------------------------------------= - Number: UK-22 Title: RANDOM_NUMBER intrinsic Status: For Consideration Basic Functionality: Independent random number generators Rationale: In N2013, Van Snyder says: "It is processor dependent whether common or independent random number generators are used, and there's no way to detect which is the situation. Therefore taking action using one assumption or the other (e.g., calling or not calling RANDOM_SEED on each image with a hopefully-different value, maybe dependent on the image number) might be the wrong thing to do. It is preferable to provide a named constant in ISO_FORTRAN_ENV to indicate whether the processor uses a common random number generator on all images, or intrinsic procedures so to inquire or specify. References to the intrinsic subroutine that specifies whether common or independent random number generators are used should be image control statements. 13.5p4 should be adjusted so that the segment ordering requirement applies only if a common random number generator is used." We would like to go further and require the processor to provide=20 independent and different sequences. In a program John Reid wrote=20 recently, he felt forced to generate his random numbers on image 1.=20 He saw no other way of staying within the standard and getting random=20 numbers. This is thoroughly unsatisfactory when we are aiming for=20 execution on large numbers of processors.=20 Bill Long commented in an email:=20 "People have long been using MPI to execute in parallel on a large=20 number of processors, and the exact same problem exists in that case. =20= The traditional solution is to use a generator with at least 2 seeds. =20= The value of one seed is the same on all MPI ranks (images), while the=20= second is unique to each rank. For a sufficiently good generator, you=20= don't do too badly." This illustrates that it is not difficult for compilers to provide adequately independent sequences. Our wording is intended to allow such an implementation, or perhaps something better. Syntax and edits: See J3/14-184 = --------------------------------------------------------------------------= - --Apple-Mail=_96A638A2-A0D9-42DE-8198-5C60BE3CD062 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_96A638A2-A0D9-42DE-8198-5C60BE3CD062--