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. The draft is available on the net, see the Fortran page.
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.
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.
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.
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.
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.
The schedule for Fortran 95 was:
An explanation of the new features follows.
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.
A FORALL statement can include a WHERE statement.
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 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 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 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.
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.
The new function NULL can be used at specification to define a pointer to be initially disassociated, see below.
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)
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 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.
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.
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".
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.
It is now permitted to use comments in the usual way with !
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.
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.