8.2 Modules and Module Procedures

A module program unit contains specifications and definitions that can be made accessible to other program units. For the module to be accessible, the other program units must reference the module in a USE statement, and the module entities must be public.

A module takes the following form:

 [prefix] MODULE name
    [specification-part]
 [CONTAINS
    module-subprogram
    [module-subprogram]...]
 END [MODULE [name]]

prefix

Is one of the following keywords:

Keyword [1]	Meaning
EXTRINSIC(HPF)	Causes the procedure to execute as if data and computation (specified by data mapping directives on Tru64 UNIX systems) are mapped by the compiler to multiple processes executing on multiple processors.
EXTRINSIC(HPF_LOCAL)	Causes multiple independent copies of the same procedure to execute on different data on multiple processors.
EXTRINSIC(HPF_SERIAL)	Causes the procedure to execute as if it were a single process executing on a scalar computer system.
[1] These keywords are allowed on all platforms, but are functional only in parallel programs on Tru64 UNIX systems. For more information on EXTRINSIC keywords, see the Compaq High Performance Fortran 90 HPF and PSE Manual.

name

Is the name of the module.

specification-part

Is one or more specification statements, except for the following:

• ENTRY

• FORMAT

• AUTOMATIC (or its equivalent attribute)

• INTENT (or its equivalent attribute)

• OPTIONAL (or its equivalent attribute)

• Statement functions

An automatic object must not appear in a specification statement.

module-subprogram

Is a function or subroutine subprogram that defines the module procedure. A function must end with END FUNCTION and a subroutine must end with END SUBROUTINE.

A module subprogram can contain internal procedures.

Rules and Behavior

If a name follows the END statement, it must be the same as the name specified in the MODULE statement.

The module name cannot be the same as any local name in the main program or the name of any other program unit, external procedure, or common block in the executable program.

A module is host to any module procedures it contains, and entities in the module are accessible to the module procedures through host association.

A module must not reference itself (either directly or indirectly).

Although ENTRY statements, FORMAT statements, and statement functions are not allowed in the specification part of a module, they are allowed in the specification part of a module subprogram.

Any executable statements in a module can only be specified in a module subprogram.

A module can contain one or more procedure interface blocks, which let you specify an explicit interface for an external subprogram or dummy subprogram.

Every module subprogram of any HPF module must be of the same extrinsic kind as its host, and any module subprogram whose extrinsic kind is not given explicitly is assumed to be of that extrinsic kind.

Examples

The following example shows a simple module that can be used to provide global data:

MODULE MOD_A
  INTEGER :: B, C
  REAL E(25,5)
END MODULE MOD_A
...
SUBROUTINE SUB_Z
  USE MOD_A               ! Makes scalar variables B and C, and array
  ...                     !   E available to this subroutine
END SUBROUTINE SUB_Z

The following example shows a module procedure:

MODULE RESULTS
...
CONTAINS
  FUNCTION MOD_RESULTS(X,Y)  ! A module procedure
  ...
  END FUNCTION MOD_RESULTS
END MODULE RESULTS

The following example shows a module containing a derived type:

MODULE EMPLOYEE_DATA
  TYPE EMPLOYEE
    INTEGER ID
    CHARACTER(LEN=40) NAME
  END TYPE EMPLOYEE
END MODULE

The following example shows a module containing an interface block:

MODULE ARRAY_CALCULATOR
  INTERFACE
    FUNCTION CALC_AVERAGE(D)
      REAL :: CALC_AVERAGE
      REAL, INTENT(IN) :: D(:)
    END FUNCTION
  END INTERFACE
END MODULE ARRAY_CALCULATOR

The following example shows a derived-type definition that is public with components that are private:

MODULE MATTER
  TYPE ELEMENTS
    PRIVATE
    INTEGER C, D
  END TYPE
...
END MODULE MATTER

In this case, components C and D are private to type ELEMENTS, but type ELEMENTS is not private to MODULE MATTER. Any program unit that uses the module MATTER can declare variables of type ELEMENTS, and pass as arguments values of type ELEMENTS.

This design allows you to change components of a type without affecting other program units that use the module.

If a derived type is needed in more than one program unit, the definition should be placed in a module and accessed by a USE statement whenever it is needed, as follows:

MODULE STUDENTS
  TYPE STUDENT_RECORD
  ...
  END TYPE
CONTAINS
  SUBROUTINE COURSE_GRADE(...)
  TYPE(STUDENT_RECORD) NAME
  ...
  END SUBROUTINE
END MODULE STUDENTS
...

PROGRAM SENIOR_CLASS
  USE STUDENTS
  TYPE(STUDENT_RECORD) ID
  ...
END PROGRAM

Program SENIOR_CLASS has access to type STUDENT_RECORD, because it uses module STUDENTS. Module procedure COURSE_GRADE also has access to type STUDENT_RECORD, because the derived-type definition appears in its host.

For More Information:

For details on procedure interfaces see Section 8.8.