17. Status of Fortran 95
Switch to the Swedish version
Some 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 my 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.
Fortran 2003 was published as ISO/IEC 1539-1:2004 on November 18, 2004.
Work on the next version of Fortran is going well, see the
official home of Fortran Standards.
- 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 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: 9 December 2004
boein@nsc.liu.se