From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Jun 17 17:39:33 2013 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 257563568E8; Mon, 17 Jun 2013 17:39:32 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-4-a-1.mail.uk.tiscali.com (mk-filter-4-a-1.mail.tiscali.co.uk [212.74.100.55]) by www.open-std.org (Postfix) with ESMTP id 6E14A3567F6 for ; Mon, 17 Jun 2013 17:39:11 +0200 (CEST) X-Trace: 861388327/mk-filter-4.mail.uk.tiscali.com/B2C/$THROTTLED_DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/88.104.241.22/None/d.muxworthy@bcs.org.uk X-SBRS: None X-RemoteIP: 88.104.241.22 X-IP-MAIL-FROM: d.muxworthy@bcs.org.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Apple Mail (2.1283) X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0CANMsv1FYaPEW/2dsb2JhbAANToM6qz6VCIMTiB6CJ6dGkh2OG4QyYQOQAYJainOORoFo X-IronPort-AV: E=Sophos;i="4.87,881,1363132800"; d="txt'?scan'208";a="861388327" Received: from 88-104-241-22.dynamic.dsl.as9105.com (HELO [192.168.1.2]) ([88.104.241.22]) by smtp.tiscali.co.uk with ESMTP; 17 Jun 2013 16:39:10 +0100 From: David Muxworthy Content-Type: multipart/mixed; boundary="Apple-Mail=_9B880196-8CB4-499E-829D-EDA0844ADEF3" Subject: N1975 - BSI proposals for revision of F2008 Date: Mon, 17 Jun 2013 16:39:10 +0100 Message-Id: To: sc22wg5@open-std.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Sender: owner-sc22wg5@open-std.org Precedence: bulk --Apple-Mail=_9B880196-8CB4-499E-829D-EDA0844ADEF3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Herewith proposals for consideration by WG5. David --Apple-Mail=_9B880196-8CB4-499E-829D-EDA0844ADEF3 Content-Disposition: attachment; filename=N1975.txt Content-Type: text/plain; name="N1975.txt" Content-Transfer-Encoding: 7bit ISO/IEC JTC1/SC22/WG5 N1975 UK PROPOSALS FOR REVISION OF FORTRAN 2008 SUBMITTED TO WG5, JUNE 2013 The BSI Fortran panel wishes to submit the following proposals for the revision of Fortran 2008 for consideration by WG5; they use the style of earlier requirements documents, e.g. N1626. -------------------------------------------------------------------------- Number: UK-01 Title: Default KINDs for constants and intrinsics Status: For Consideration Basic Functionality: Program-specified default KIND for constants etc. Rationale: (a) In the 64-bit world default integer generally being 32-bit is increasingly leading to incorrect programs. (b) In the floating-point world default real generally being 32-bit not infrequently leads to incorrect programs. (c) It is tedious and error-prone to have to attach kind_param's to individual literal constants. (d) It is tedious and error-prone to have to specify a KIND= argument as required for each individual reference to an intrinsic function. (e) Program specification of the default type parameters is possible for derived types but not intrinsic types. Specification (requirements): 1. Provide a mechanism for specifying the default kind parameter for the intrinsic types REAL and INTEGER. 2. Decouple the concepts of "default kind" from those of "single precision" and "basic integer"; "default kind" to be used for literal constants, implicit typing, etc., while "single precision" et al to be used for the old storage association contexts. Discussion: Specifications (detailed): -------------------------- a. There will be a new statement, that can appear only between the USE statements and IMPLICIT statements, to specify the default kind for a particular intrinsic type. b. The effect of this statement is to change the default kind for the remainder of the scoping unit. To avoid circular dependencies, it does not affect the default kind of literals appearing in or before the statement itself, nor does it affect the type implied by a PARAMETER statement that appears before the statement. Rationale: circular dependencies bad, named constants good. c. The default kind setting in a scoping unit is initially that of its host scoping unit; note that as nested scoping units appear necessarily after any IMPLICIT statements, this will inherit the user setting. d. In the case of REAL, the default kind for COMPLEX is also affected. It does not affect double precision kind, which remains as twice single precision in storage. e. Terminology: "default kind" = user-specifiable default kind "single precision kind" = old default real kind "basic integer kind" = old default integer kind f. OPTIONAL: There is a reasonable argument to be made that permitting the user to specify the kind for "double precision" constants and variables would also be valuable. g. Table of places where "default kind" is used, and what that should correspond to in the new scheme, follows. Context Should be --------------------------------------------------------- (1) integer literal with no default kind (2) "kindly" intrinsics with absent KIND= default kind * Note T0 (3) intrinsics with no KIND argument default kind * Note T1 (4) with no KIND parameter, e.g. REAL default kind * Note T2 (5) arguments to generic intrinsics accept both * Note T3 (6) args/result for specific intrinsics, e.g. AMIN1 basic kind * Note T4 (7) constants in ISO_FORTRAN_ENV basic kind * Note T5 (8) having the size of one numeric storage unit basic kind (9) EQUIVALENCE/COMMON real/integer matching basic kind Note T0. This includes LBOUND, LCOBOUND, SIZE, SHAPE ... i.e. all the ones that have a KIND= argument and return a REAL/INTEGER/COMPLEX result of the specified kind when present, and default kind when not. Note T1. Actually these don't really matter much, as the value always fits into basic kind. However, it would be more convenient when passing as an actual argument, and more consistent, for these to be the new user-specifiable default kind too. Here is a representative list of the intrinsics concerned: DIGITS, PRECISION, RANGE, EXPONENT, MAX_EXPONENT, and THIS_IMAGE. Note T2. Wherever the is, viz a type declaration statement, component definition statement, array constructor, etc. Note T3. The affected intrinsics:arguments are DATE_AND_TIME: VALUE, EXECUTE_COMMAND_LINE:EXITSTAT,CMDSTAT, GET_COMMAND:LENGTH,STATUS, and similar. Not a big deal (values always representable in the basic kind) but why not relax the requirement to permit larger kinds always anyway? Note T4. Not actually important. These are wholly redundant anyway. Note T5. As if it were a user-defined module with those constants. Syntax (illustrative): ---------------------- DEFAULT ( [ KIND = ] ) where is INTEGER or REAL. Cnnn (Ryyy) The kind number specified in a DEFAULT INTEGER statement shall specify a kind whose storage size is at least as great as that of basic integer kind. {Reason: To stop the user shooting his foot off with a short integer kind.} OPTIONAL: If we permit specification of double precision kind, add this additional syntax: DEFAULT DOUBLE PRECISION ( [ KIND = ] ) Cnnn The kind number specified in a DEFAULT DOUBLE PRECISION statement shall not specify a kind whose storage size is less than that of default real kind. {Reason: There might not be a bigger real kind than the user-specified default, but it would be counter-intuitive to permit specification of a double precision kind that is actually smaller than default real.} Example: -------- This is just to show how it works, it is too trivial to show much advantage. Program sum_tan_prefix Default Integer (Kind=Selected_Int_Kind(18)) Default Real (Kind=Selected_Real_Kind(15)) Real,Allocatable :: x(:) Print *,'Input vector length N' Read *, n If (n<2) Stop 'Don''t be silly.' Allocate(x(n)) Print *,'Input vector with',Size(x),'values in degrees' Read *,x tmp = 0 Print *,'SUM_TAN_PREFIX results' Do i=1,Size(x) tmp = tmp + Tan(x(i)*3.1415926535897932384/180) Print *,i,x End Do End Program -------------------------------------------------------------------------- Number: UK-02 Title: Further control of inheritance Status: For Consideration Basic Functionality: Enable specification of the default accessibility for entities accessed from a module. Rationale: If module B uses module A, the default accessibility for entities accessed from A is PUBLIC. Specifying another accessibility for each entity is awkward and error prone. It should be possible to specify the default. Specifications: 1. In a module, the default accessibility of entities from another module accessed by use association should be decoupled from the default accessibility of entities defined by the using module. 2. This should be done by a separate statement, not on the USE statement, to avoid confusion when multiple USE statements for a module appear. 3. Multiple specifications of the default accessibility shall not be permitted. 4. Specification of accessibility shall not be permitted for a module that is not referenced by a USE statement. Syntax: 1. Permit a module name to appear in a PUBLIC or PRIVATE statement. 2. At most one appearance of a module name in all the PUBLIC and PRIVATE statements in a module specification part is permitted. Example: Module m ! We need all these modules... Use iso_c_binding Use iso_fortran_env Use ieee_arithmetic ! And we want default public for our own stuff... Public ! But we don't want to export stuff from the other modules... Private iso_c_binding, iso_fortran_env, ieee_arithmetic -------------------------------------------------------------------------- Number: UK-03 Title: RECL for unlimited records Status: For Consideration Basic Functionality: RECL for unlimited records Rationale: If INQUIRE is used on a file with unlimited record length, the value returned by RECL is processor dependent. It should be defined. Specification: Specify a value, for example HUGE(0). -------------------------------------------------------------------------- Number: UK-04 Title: FORMAT inconsistencies Status: For Consideration Basic Functionality: Remove some FORMAT inconsistencies Rationale: Improve consistency. Specification: 1. It is a anomalous that G0.m is allowed but E0.m is not, especially as this will often complicate the implementation. In 10.7.2.1 paragraph 1(6), E, EN and ES should be added to the list of descriptors that can take a width of zero. 2. The following enhancements would allow the printing of numbers in a maximally compact scientific form: 2.1 Allow En.mE0, ENn.mE0 and ESn.mE0 to have the meaning that the exponent is of one of the forms E+0 or E+-, where does not begin with a zero. 2.2 Add an INQUIRE, OPEN and WRITE specifier EXPONENT_WIDTH= that specifies the default exponent width (i.e. the forms En.m, ENn.m and ESn.m would behave like En.mE etc.) 2.3 Extend points (2.1) and (2.2) above to the G descriptor. 3. It is an anomaly that the sign is suppressible for the mantissa but not the exponent. -------------------------------------------------------------------------- Number: UK-05 Title: Improve the generic disambiguation rules Status: For Consideration Basic Functionality: Improve the generic disambiguation rules in 12.4.3.4.5 Rationale: The disambiguation rules of C1215 fail certain cases, for example: Interface g Procedure p1,p2 End Interface where the procedures p1 and p2 are Subroutine p1(fun) and Subroutine p2(sub,fun) External :: fun External sub,fun because (a) subroutines are not distinguishable from functions (b) the rules about "number of nonoptional arguments" applies only to dummy data objects, not to dummy procedures. Syntax: Add a new list item in constraint C1215: "(1.5) the number of nonoptional dummy procedures in one of them exceeds the number of dummy procedures in the other," -------------------------------------------------------------------------- Number: UK-06 Title: Remove restriction on ERROR STOP Status: For Consideration Basic Functionality: Remove restriction on error-stop Rationale: There is no standard way to issue a diagnostic message from a PURE procedure. A program should be able to execute an error termination with a meaningful message. Specification: Remove the restriction on the appearance of an ERROR STOP statement in a PURE procedure. Syntax: Delete 'or <>" in C1287 [313:8]. -------------------------------------------------------------------------- Number: UK-07 Title: Numeric conversion check Status: For Consideration Basic Functionality: Numeric conversion check Rationale: It is tedious to check if values of one intrinsic type can be converted to a another without error. Specification: Add new logical intrinsic functions: OUT_OF_RANGE_FOR_INT (X, [ KIND]) This function returns .TRUE. if the result of truncating the real X to an integer in the direction of zero is not representable as a default integer (KIND absent) or an integer of kind KIND (KIND present). Otherwise, it returns .FALSE. OUT_OF_RANGE_FOR_NINT (X, [ KIND]) This function returns .TRUE. if the result of truncating the real X to the nearest integer is not representable as a default integer (KIND absent) or an integer of kind KIND (KIND present). Otherwise, it returns .FALSE. OUT_OF_RANGE_FOR_REAL (A, [KIND]] This function returns .TRUE. if the value A is outside the range of representable values for objects of type REAL with kind KIND (or default KIND if KIND does not appear), or if A is finite and REAL(A,KIND) would be infinite. Otherwise, it returns .FALSE. --------------------------------------------------------------------- Number: UK-08 Title: New reduction intrinsic Status: For Consideration Basic Functionality: Rationale: It is anomalous that we are proposing to add CO_REDUCE to a language without REDUCE. Specification: Add a new intrinsic function REDUCE (ARRAY, OPERATOR, DIM [, MASK]) or REDUCE (ARRAY, OPERATOR [, MASK]) ARRAY is an array of any type, OPERATOR is defined as in N1967 (the draft TS for further coarray features), and DIM and MASK are as for SUM. The computation is defined as in N1967. The characteristics of the result are as for SUM. Note. It might be more appropriate to add this to N1967. ------------------------------------------------------------------- Number: UK-09 Title: IEEE Arithmetic. Status: For Consideration Basic Functionality: Update external references to IEEE arithmetic. Rationale: IEC 60559:1989 has been superseded by IEC 60559:2011. Specification: The 54 references to IEC 60559:1989 and the one reference to IEEE 754-1985 should be reviewed for change to IEC 60559:2011 and IEEE 754-2008 respectively. -------------------------------------------------------------------------- Number: UK-10 Title: New deletions and obsolescences Status: For Consideration Basic Functionality: Revise deletions and obsolescences Rationale: 1a. Arithmetic IF has been deemed obsolescent since Fortran 90 and conflicts with IEC 60559. It should be deleted. 1b. Shared DO termination and termination on a statement other than END DO or CONTINUE have been similarly obsolescent and cause confusion and program errors. They should be deleted. 2a. Although useful prior to F90, EQUIVALENCE is now confusing, error-prone, and is not needed for reducing memory usage. It can reduce performance, and is superseded by complex part specifiers. 2b. COMMON is error-prone, largely redundant with modules, and can reduce performance. 2c. Implicit interfaces are error-prone and redundant with explicit interfaces except when a dummy or procedure pointer has a different argument list at different times, and this functionality can be emulated with C_FUNLOC plus C_F_PROCPOINTER. 2d. The label on a block DO construct has always been entirely superfluous and merely provides an opportunity for confusion. 2e. Specific names for intrinsic functions have been redundant since F90. They should be declared obsolescent. 2f. The FORALL construct has failed in its purpose of enabling better performance and is redundant with the DO construct, especially the CONCURRENT form. 3. Deeming the CHARACTER* form of the CHARACTER statement to be obsolescent is now seen to be a mistake. It should be restored to full language status. Specification: 1. Move items (1) and (2) of B.2.1 to B.1 (Deleted features). 2. Add the following outdated features to B.2 (Obsolescent features): - The EQUIVALENCE statement. - The COMMON statement and BLOCK DATA program unit. - Implicit interfaces for procedures. - The DO label statement. - The specific names for standard intrinsic functions. - The FORALL construct. 3. Delete item (9) of B.2.1 and all of subclause B.2.8, that is restore the CHARACTER* form of the CHARACTER statement to full language status, with corresponding font changes throughout the document. ----------------------------------------------------------------------- --Apple-Mail=_9B880196-8CB4-499E-829D-EDA0844ADEF3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_9B880196-8CB4-499E-829D-EDA0844ADEF3--