MODULEs

• Probably the most significant addition to Fortran 90/95 over and above Fortran 77.
  
  
• Can be used for:
  • packaging global data;
  • packaging derived types and their associated operations (encapsulation);
  • weak object orientation;
  • making explicit interfaces of (legacy) external procedures (by wrapping using an INTERFACE block);
  • packaging libraries with PRIVATE and PUBLIC components;
  • more...

Global Data Access

• Information is normally passed between subprograms via arguments.
• This mechanism can prove cumbersome:
  • large number of arguments for many subprograms;
  • arguments used at the bottom of a deep call stack (unused in the middle);
• Old-fashioned global variables are crude --- no access control what-so-ever.

Example

• Compare with the obsolete COMMON block;

  MODULE state_variables
    INTEGER, PARAMETER      :: NX=100, NY=200
    REAL, DIMENSION(NX, NY) :: temp, pres
  END MODULE state_variables

  PROGRAM
    USE state_variables

    DO IY = 1, NY
        DO IY = 1, NY
            CALL update_temp(IX, IY)
            CALL update_pres(IX, IY)
        END DO
    END DO
  END PROGRAM

  ! -- external subprogram :
  SUBROUTINE update_temp(I,J)
    USE state_variables
    INTEGER, INTENT(IN) :: I, J

    temp(I,J) = ...
  END SUBROUTINE

• Could develop further: make temp and pres PRIVATE and provide read/write methods.

Module Procedures

• all subprogram interfaces are explicit:
  • to other subprograms within the MODULE;
  • to CALLers which USE the MODULE;
  
  
• subprograms may be PUBLIC or PRIVATE;

Example

MODULE related_procedures PUBLIC :: sub_1 PRIVATE :: sub_2, sub_3 CONTAINS SUBROUTINE sub_1(A,B) REAL, INTENT(IN) :: A(:) INTEGER, INTENT(IN) :: B ... CALL sub_2(B) CALL sub_3(B) ... END SUBROUTINE sub_1 SUBROUTINE sub_2(C) REAL, INTENT(IN) :: C(:,:) ... END SUBROUTINE sub_2 SUBROUTINE sub_3(D) INTEGER, INTENT(IN) :: D ... END SUBROUTINE sub_3 END MODULE related_procedures

Type and Procedure Packaging (Encapsulation)

• There are no intrinsic operations for user-defined TYPEs.
  
  
• Two objects are of the same TYPE if and only if they are declared using a reference to the same unique type definition. Therefore it is not enough for an actual and a dummy argument to match in type by just including identical type definitions.
  
  
• Natural to group subprogrammes designed for manipulation of a derived type together with that derived type within a MODULE.

Example

Encapsulation of a derived TYPE and its associated subprogrammes yields the beginnings of object-oriented programming :

MODULE Houses TYPE House PRIVATE ! -- components of House can be ! accessed by MODULE subprogrammes ! only; CHARACTER(LEN=32) :: owner INTEGER :: residents REAL :: value END TYPE House CONTAINS SUBROUTINE set_value(H, val) TYPE(House), INTENT(INOUT) :: H REAL, INTENT(IN) :: val H%value = val END SUBROUTINE FUNCTION value(H) TYPE(House), INTENT(IN) :: H REAL :: value value = H%value END FUNCTION END MODULE Houses

The USE Statement

Usually simply

USE module_name

This makes all PUBLIC entities defined within module_name accessible.

Name clashes can occur --- one remaining maintainability problem in Fortran? Workaround: --- the local name Set_House_Value references the module-procedure (declared within House) Set_Value :

USE House, Set_House_Value => Set_Value

(In Fortran 77 the problem is insoluble.)

This form reduces the chance of a name-clash and is a "safer" option from a software-engineering standpoint :

USE My_Module, ONLY: Sub_1, Sub_2

Remark

• Most languages require or permit access to module entities via

  module.variable

  or

  module.procedure

  The Fortran 90/95 standard does not.
  
  
• The Committee (apparently) supposed the Fortran way was simpler. This is demonstrably not the case and leads to all sorts of problems for code maintainence and multi-author projects.

Making interfaces explicit (INTERFACE)

• See later...