Implementations with Extended Fortran support must provide:
An MPI implementation must provide a module named mpi that can be USEd in a Fortran 90 program. This module must:
 
The appropriate  INTENT may be different from what is given in the  
 MPI generic interface. Implementations must choose  INTENT so that  
the function adheres to the  MPI standard.  
 ( End of advice to implementors.) 
 
  
 
 
 Rationale.  
 
The intent given by the  MPI generic interface is not precisely  
defined and does not in all cases correspond to the correct Fortran  
 INTENT. For instance, receiving into a buffer specified by a datatype  
with absolute addresses may require associating  MPI_BOTTOM  
with a dummy  OUT argument.  Moreover, ``constants'' such as  
 MPI_BOTTOM and  MPI_STATUS_IGNORE are not constants  
as defined by Fortran, but ``special addresses'' used in a nonstandard  
way.  Finally, the  MPI-1 generic intent is changed in several places  
by  MPI-2. For instance,  MPI_IN_PLACE changes the sense of  
an  OUT argument to be  INOUT.  
 ( End of rationale.) 
 
  
 
Applications may use  either the  mpi module or the  
 mpif.h include file. An implementation may require  
use of the module to prevent type mismatch errors (see below).   
 
 
 Advice to users.  
 
It is recommended to use the  mpi module even if it  
is not necessary to use it to avoid type mismatch errors  
on a particular system. Using a module provides several   
potential advantages over using an include file.  
 ( End of advice to users.) 
 
It must be possible to link together routines some of which  USE  mpi  
and others of which  INCLUDE  mpif.h.   
A high quality MPI implementation should provide a mechanism to ensure that MPI choice arguments do not cause fatal compile-time or run-time errors due to type mismatch. An MPI implementation may require applications to use the mpi module, or require that it be compiled with a particular compiler flag, in order to avoid type mismatch problems.
 
 
 
 Advice  
        to implementors.  
 
In the case where the compiler does not generate errors, nothing needs  
to be done to the existing interface.  In the case where the compiler  
may generate errors, a set of overloaded  
functions may be used.  See the paper of M. Hennecke [8].  
Even if the compiler does not generate errors, explicit interfaces for  
all routines would be useful for detecting errors in the argument  
list. Also, explicit interfaces which give  INTENT information   
can reduce the amount of copying for  BUF(*) arguments.   
 ( End of advice to implementors.)