0

Sometimes I want to include a module in some other subroutine but I only need several subroutines from that module. What is the difference between 

use a_module,  only: a_subroutine

or simply 

use a_module

?

Vladimir F Героям слава
  • 57,977
  • 4
  • 76
  • 119
Lychee
  • 19
  • 1
  • 4
    What are your criteria for determining which practice is *better* ? Without a clear and objective set of criteria your question and any answers to it will be opinion-based and therefore off-topic. – High Performance Mark Sep 15 '14 at 16:00
  • restricting the `use` to `only` what you need prevents conflict should you use the same symbol names as things defined in the module (but not used) for some other purpose. It also arguably aids readability by telling us why you are `use`ing the module. Other that that it doens't make any difference. this is not such a bad question, folks on here are harsh!. (perhaps 'whats the difference' rather that 'which is better' would be a better way to ask.) – agentp Sep 15 '14 at 18:27
  • For me, limiting the inclusion of `use` statement only to the subroutine, where it is necessary, instead of the whole module is most often enough to avoid the namespace pollution. Opinion of others may vary. – Vladimir F Героям слава Sep 15 '14 at 19:05
  • I have to second @VladimirF's statement. A coworker introduced the variable `size` in public namespace and, thus, shadowed the intrinsic function with the same name. It took ages, to find this error, which wouldn't have happened, if all modules would have been included via `use [module] : only [subroutine]`. – Stefan Sep 16 '14 at 05:14
  • Ups, I wrote it in an ambiguous way. For me, I use the `only` clause when the `use` statement is inside a module. If it is inside a small subroutine I often don't bother and just `use` the whole module. – Vladimir F Героям слава Sep 16 '14 at 05:44
  • Thank you very much. I just want to learn the 'good and proper' practice of a programmer. Sorry for the ambiguity of not specifying a criterion. I should have asked the question as george said though. – Lychee Sep 16 '14 at 23:40
  • In opposition to Vladimir F, I prefer to keep USE statements at the top of modules only (never in the procedures contained by that module), each use statement having obligatorily the ONLY clause : so just glancing at the top of the module is enough to understand all its dependencies... – Francois Jacq Sep 18 '14 at 16:57
  • Does this answer your question? [How do you USE Fortran 90 module data](https://stackoverflow.com/questions/1240510/how-do-you-use-fortran-90-module-data) – veryreverie Apr 24 '22 at 16:11

1 Answers1

1

Here is a complete answer, some of which has already been discussed in the comments.

From Metcalf et al. (2011) p.146 (a leading Fortran reference textbook), use a_module provides (emphasis added):

access to all the public named data objects, derived types, interface blocks, procedures, generic identifiers, and namelist groups in the module named.

Conversely, use a_module, only an_entity provides:

access to an entity in a module only if the entity ... is specified.

i.e. use a_module is equivalent to the not-recommended (e.g. in [2]) python practice:

from a_module import *

while use a_module, only an_entity is equivalent to the preferred python practice:

from a_module import an_entity

Unfortunately, the recommended python practice

import module [as name]

or

import module.submodule [as name]

is not available in Fortran since Fortran imports all entities into a global namespace rather than accessing entities from modules via the module's namespace as done in python, e.g.:

import numpy as np
array = np.array([1, 2, 3])

As noted in the comments and elsewhere (e.g. [3]), explicit imports (use a_module, only an_entity) are preferred over implicit imports (use a_module) for code clarity and to avoid namespace pollution / name clashes ("explicit is better than implicit").

Metcalf et al. (2011) also note that should you require two entities with the same name from different modules, name clashes can be avoided by renaming one (or both) of the clashing entities locally (i.e. within your program / module only), e.g.

use stats_lib, only sprod => prod
use maths_lib, only prod

where prod from stats_lib is accessed locally using the name sprod, while prod from maths_lib is accessed locally using the name prod.

Incidentally, Metcalf et al. (2011) also note:

A name clash is permitted if there is no reference to the name in the scoping unit.

i.e. you can successfully compile:

use stats_lib
use maths_lib

without problems provided neither module's prod (or any other clashing name) is used in your program / module. However, for the reasons above, such practice is not recommended.

[1] Metcalf, M, Reid, J & Cohen, M. (2011) "Modern Fortran Explained" (Oxford University Press)

[2] https://www.tutorialspoint.com/python/python_modules.htm

[3] http://www.fortran90.org/src/best-practices.html

Biggsy
  • 1,306
  • 1
  • 12
  • 28