Unlike main programs and external subprograms, modules are not themselves executable program units. Rather, they contain definitions that can be conveniently accessed and used by executable program units. For example, a module might contain interface blocks for a library of external procedures and be used to make the interfaces of these library procedures explicit in an application using that library. A likely growing trend is to repackage the entire library in a module-that is, to place all of the procedure definitions in a module (assuming the procedures can be written in Fortran)-which has the twin benefits to an application of making the procedure interfaces explicit without the need for interface blocks and giving the application developer a powerful tool for namespace management.
Data related uses of modules are just as important as procedure related uses. User-defined type definitions can be placed in a module and thus made available to the other program units of an application , and indeed this is the preferred way of packaging most type definitions. Data objects, of any type, kind, and shape can be declared in a module and thus become global data objects for an application using that module. This provides a non- storage-associated global data alternative to COMMON, which can be used where storage association is a problem (e.g., in distributed memory environments). Arrays in modules can be allocatable, thus providing a means of having dynamic arrays conveniently accessible to any of the program units of the application.