17. Status of Fortran 95
Switch to the Swedish version
Most of the new features are from HPF.
Fortran 95 was published as ISO/IEC 1539-1:1997 on December 15,
1997.
The preliminary revision has been published as "Special Issue,
Fortran 95, Committee Draft, May 1995" in the Fortran Forum,
Vol. 12, No. 2, June 1995.
Two important issues, exception handling, especially for
floating point, and interoperability between languages (mixed
language programming) are not addressed in Fortran 95. Exception
handling is discussed in some papers by John Reid, see the proceedings
of the Kyoto Workshop on Current Directions in Numerical Software
and High Performance Computing.
- The statement FORALL
as an alternative to the DO-statement
- Partial nesting of FORALL
and WHERE statements
- Masked ELSEWHERE
- Pure procedures
- Elemental procedures
- Pure procedures in specification expressions
- Revised MINLOC and MAXLOC
- Extensions to CEILING and FLOOR with the
KIND keyword argument
- Pointer initialization
- Default initialization of derived type objects
- Increased compatibility with IEEE arithmetic
- A CPU_TIME intrinsic subroutine
- A function NULL to nullify a pointer
- Automatic deallocation of allocatable arrays at exit of scoping
unit
- Comments in NAMELIST at input
- Minimal field at input
- Complete version of END INTERFACE
Pure functions are functions without side effects, and elemental functions
are pure functions with only scalar arguments and with scalar result.
Five features are deleted from Fortran 90.
- real and double precision DO loop index variables
- branching to END IF from an outer block
- PAUSE statements
- ASSIGN statements and assigned GO TO statements
and the use of an assigned integer as a FORMAT specification
- Hollerith editing in FORMAT
These are all from the list of obsolescent
features of Fortran 90 (but not the complete list).
It is permitted for a compiler to have extensions to the standard,
provided that these can be flagged by the system. It is very
common for compilers to include the two features (see
Appendix 4) that were removed from Fortran when Fortran 77 was
introduced, and it is expected that this tradition will continue.
17.3 Obsolescent features
In the obsolescence list below those items that were not in the
corresponding list of Fortran 90
are indicated . All items in the
list below are being considered for removal at the next revision,
and should therefore be avoided.
The most probable candidates, in our opinion, for removal at the
next revision (in the next century) are the first six.
- Arithmetic IF-statement
- Terminating several DO-loops on the same statement
or terminating the DO-loop in some other way than with
CONTINUE or END DO
- Alternate return
- Computed GO TO statement
- Statement functions
- DATA statements among executable statements
- Assumed character length functions
- Fixed form source code
- CHARACTER* form of CHARACTER declaration
To replace CHARACTER*LENGTH with CHARACTER(LEN=LENGTH)
or CHARACTER(LENGTH) is simple, as are the other
items above. For example, item 6 is just to move all DATA
statements to the top of the program unit, before the executable
statements. Statement functions
are of course replaced with internal
functions.
17.4 Schedule
The expected schedule for Fortran 95 is as follows.
- April 1995: Technical completion
- End of May 1995: Document available
- July - September 1995: Review and ISO CD ballot
- November 1995: Revision based on ballot comments
- March 1996: Revised document available
- 26 January 1997: End of the ISO DIS international ballot
- 15 December, 1997: Fortran 95 published as ISO/IEC 1539-1:1997
(replacing Fortran 90, ISO/IEC 1539:1991).
17.5 Description of the new features
An explanation of the new features follows.
-
The statement FORALL
The statement FORALL
is introduced as an alternative to the DO-statement.
The main difference is that while the execution order of the various
parts of the DO-loop is very strict, the execution order
of the FORALL is less strict, thus permitting parallel
execution. For further information we refer to our HPF
Appendix or directly to the HPFF
home page.
-
Partial nesting of FORALL and
WHERE statements
A FORALL statement can include a WHERE statement.
-
Masked ELSEWHERE
It is now permitted to mask not only the WHERE statement
of the WHERE construct, but also its ELSEWHERE,
which now may be repeated.
WHERE (condition_1)
...
ELSEWHERE (condition_2)
...
ELSEWHERE
...
END WHERE
-
Pure procedures
Pure functions are functions without side effects. That a function
has no side effects can be indicated with the new PURE
prefix.
A long list of constraints is given in the standard proposal,
section 12.6.
Pure subroutines are defined in a similar way. The only major
difference is that "side effects" are of course permitted for
arguments associated with dummy arguments specified INTENT(OUT)
or INTENT(INOUT).
The advantage with knowing that a function is pure is that
this fact simplifies parallel execution.
-
Elemental procedures
Elemental functions are pure functions with only scalar dummy
arguments (not pointers or procedures) and with scalar result
(not pointer). That a function is elemental can be indicated with
the new ELEMENTAL prefix. The RECURSIVE prefix
my not be combined with the ELEMENTAL prefix. The PURE
prefix is automatically implied by the ELEMENTAL
prefix.
An elemental function may be used with arrays as actual arguments.
These must then be conformable. The result is the same array
as if the function had been used individually with each of the
array elements, in any order.
Elemental subroutines are defined in a similar way. The only
major difference is that "side effects" are of course permitted
for arguments associated with dummy arguments specified INTENT(OUT)
or INTENT(INOUT).
The advantage with knowing that a function is elemental is
that this fact simplifies parallel execution, even more than
if it is only pure.
-
Pure procedures in specification expressions
Pure functions can be used in specification expressions if certain
conditions are fulfilled, see the standard proposal, section 7.1.6.2.
Specification expressions can be used to specify array bounds
and character lengths of data objects in a subprogram.
-
The array location functions MINLOC
and MAXLOC are extended with the optional argument
DIM corresponding to those for the array functions MINVAL
and MAXVAL.
-
Extensions to CEILING and FLOOR
The new numerical functions CEILING
and FLOOR are extended with the KIND
keyword argument, in the same way as for INT and NINT.
The result is an integer, but of the specified KIND
or subtype, not necessarily the standard (default) integer subtype.
-
Pointer initialization
The new function NULL can be used at specification to
define a pointer to be initially disassociated, see below.
-
Default initialization of derived type objects
Means are now available to specify default initial values for
derived type components. It is the usual way of using the equal
sign (or pointer assignment) followed by the value (perhaps an
array constructor). Initialization does not have to apply to all
components of a certain derived type.
A simple example. In Appendix
3, section 12, we introduced a sparse matrix.
A numerically interesting example is a sparse matrix A
with at most one hundred non-zero elements, which can
be specified with the following statement, where now initialization
is done to 2.0 for all elements.
TYPE NONZERO
REAL :: VALUE = 2.0
INTEGER :: ROW, COLUMN
END TYPE
and
TYPE (NONZERO) :: A(100)
You then get the value (which will be 2.0) of A(10)
by writing A(10)%VALUE. The default value can be individually
changed with an assignment, for example
A(15) = NONZERO(17.0,3,7)
-
Increased compatibility with IEEE arithmetic
The IEEE arithmetic has for floating point numbers one bit pattern
for plus zero and another one for minus zero. Processors
that distinguish between them shall treat them as identical
- In all relational operations
- As input arguments to all intrinsics except SIGN
- As the scalar expression in the arithmetic IF-statement
In order to distinguish between the two cases, the function SIGN
has to be used. It is generalized so that the sign of
the second argument is considered also if the value is a floating-point
zero.
-
A CPU_TIME intrinsic subroutine
The subroutine CPU_TIME(TIME) belongs of course to
intrinsic subroutines. In the
scalar real variable TIME the present processor time
is returned in seconds. If the processor is unable to provide
a timing, a negative value is returned instead. As usual, the
time for a certain computation is obtained by subtracting two
different calls to the timing routine.
The exact nature of the timing is implementation dependent,
a parallel processor might reurn an array of times corresponding
to the various processors. The difference between CPU-time and
system time is also implementation dependent.
-
A function NULL to nullify a pointer
This function can be used at specification to define a pointer
to be initially disassociated, in the example below the array
VECTOR.
REAL, POINTER, DIMENSION(:) :: VECTOR => NULL()
The argument is not necessary, if present it determines the characteristics
of the pointer, if not present, the characteristics are determined
from context.
The function belongs to section
20, pointer inquiry functions, which is now renamed "Pointer
association status functions".
-
Automatic deallocation of allocatable arrays at exit of scoping
unit
If the user has not explicitly deallocated local allocatable arrays
at the exit of the scoping unit, this deallocation is now performed
automatically, thus decreasing the memory required.
-
Comments in NAMELIST at input
It is now permitted to use comments in the usual way with !
-
Minimal field at output
In order to obtain an optimized use of the available positions
it is now possible to only give the number of decimals, if any,
and not the total field width, at the FORMATs B,
F, I, O, and Z. Examples are I0 and F0.6.
The result is of course not a field with zero digits, but with
a suitable number of digits.
-
Complete version of END INTERFACE
Also END INTERFACE can now be given in a complete variant,
so the second interface in chapter 10 can
be given either in the old version as
INTERFACE SWAP
MODULE PROCEDURE SWAP_R, SWAP_I, SWAP_C
END INTERFACE
or in the new preferred way as
INTERFACE SWAP
MODULE PROCEDURE SWAP_R, SWAP_I, SWAP_C
END INTERFACE SWAP
This can also include an optional generic specification.
Last modified: 11 September 1998
boein@nsc.liu.se |