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 <kind-param>            default kind
(2) "kindly" intrinsics with absent KIND=           default kind * Note T0
(3) intrinsics with no KIND argument                default kind * Note T1
(4) <type-spec> 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 <type-spec> 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 <intrinsic-type-name> ( [ KIND = ] <int-constant-expr> )
     where <intrinsic-type-name> 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 = ] <int-constant-expr> )
   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+-<digits>, where <digits>
    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<EXPONENT_WIDTH> 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 <<error-stop-stmt>>" 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.  
-----------------------------------------------------------------------