Progress on Fortran 2003 and the Technical Report on Enhanced Module Facilities

Prepared for the BCS Fortran Specialist Group Meeting, May 19 2004

Since last year's AGM, WG5 has constructed a Final Committee Draft of Fortran 2003 which was subject to country balloting from 13 October 2003 to 13 February 2004. This passed with 7 yeses, 3 yeses with comments, and 2 abstentions. The comments were all minor and were almost all accepted at the WG5 meeting, May 2-7. The only issue of debate was whether private procedures were permitted to have binding labels (it was decided that they should). A Draft International Standard has constructed and I have forwarded this to the secretariat for balloting. This is a simple yes/no ballot. Only extremely minor corrections (such as formatting or typos) are permitted before publication. Essentially, the Fortran 2003 standard has been completed. It should be published later this year.

Also completed at the May meeting was the Technical Report (TR) on Enhanced Module Facilities, and I have forwarded this, too, to the secretariat for ballot. It is a sort of mini standard, with less formal hurdles, and is designed to ease the construction of huge programs. It is written as an extension of Fortran 2003 and there is a promise that it will be incorporated in the next standard, apart from any glitches found in practice, but it could also be implemented as an extension to Fortran 95. It will be the main topic of this talk. I will explain the problem that it addresses and how it will help.

The Draft International Standard and the Draft Technical Report are available as documents N1601 and N1602 from the WG5 website. I would like once more to take the opportunity to thank NAG for providing this facility.

The module facilities of Fortran 95, while adequate for programs of modest size, have shortcomings for very large programs. They all arise from the fact that, although modules are an aid to modularization of the program, they are themselves difficult to modularize.

As a module grows larger, the only way of modularize it is to break it into several modules. This exposes the internal structure, raising the potential for unnecessary global name clashes and giving the user of the module access to what ought to be private data and/or procedures. Worse, if the subfeatures of the module are interconnected, they must remain together in a single module, however large.

Another significant shortcoming is that if a change is made to the code inside a module procedure, even a private one, typical use of make or similar tools results in the recompilation of every file which accesses the module, directly or indirectly.

The solution is to allow a module procedure to have its interface defined in a module while its body is defined in a separate program unit called a submodule. A change in a submodule cannot alter an interface, and so does not cause the compilation of program units that use the module.

A submodule has access via host association to entities in the module, and may have entities of its own in addition to providing implementations of module procedures.

Here is a simple example:

      module points
         type :: point
            real :: x,y
         end type point
         interface 
            real module function point_dist (a,b)
               type(point), intent(in) :: a,b
            end function point_dist 
         end interface
      end module points
      
      submodule (points) points_a
      contains 
         real module function point_dist (a,b)
            type(point), intent(in) :: a,b
            point_dist = sqrt((a%x-b%x)**2+(a%y-b%y)**2)
         end function point_dist 
      end submodule points_a

The interface specified in the submodule must be exactly the same as that specified in the interface block. There is also a syntax that avoids the redeclaration altogether:

      submodule (points) points_a 
      contains 
         module procedure point_dist
            point_dist = sqrt((a%x-b%x)**2+(a%y-b%y)**2)
         end procedure point_dist 
      end submodule points_a

Submodules are themselves permitted to have submodules, which is useful for very large programs. If a change is made to a submodule, only it and its descendants will need recompilation.

A submodule is identified by the combination of the name of its ancestor module and the name of its parent, for example, points:points_a for the above submodule. This allows two submodules to have the same name if they are descendants of different modules.

A major benefit of submodules is that if a change is made to one, only it and its descendants are affected. Thus a large module may be divided into small submodule trees, improving modularity (and thus maintainability) and avoiding unnecessary recompilation cascades. Entities declared in a submodule are private to that submodule and its descendants, which controls their name management and accidental use within a large module.

Separate concepts with circular dependencies can be separated into different submodules in the common case where it is just the implementations that reference each other (because circular dependencies are not permitted between modules, this was impossible before).

Where a large task has been implemented as a set of modules, it may be appropriate to replace this by a single module and a collection of submodules. Entities that were public only because they are needed by other modules of the set can become private to the module or to a submodule and its descendants.

Once the implementation details of a module have been separated into submodules, the text of the module itself can be published to provide authoritative documentation of the interface without exposing any trade secrets contained in the implementation.

On many systems, each source file produces a single object file that must be loaded in its entirety. Breaking the module into several files will allow the loading of only those procedures that are actually invoked into a user program. This makes modules more attractive for building large libraries.

Comments on this or any other of the Group's pages should be sent by e-mail to the BCS FSG Web Editor, Peter Crouch, at pccrouch@bcs.org.uk