Modules: code with a name
A module puts procedures and constants in one named place, and `use` brings them in. It is how Fortran code is shared without copying it, and how the compiler checks every call.
A named box
A module begins with module name, holds declarations and — after contains — procedures, and ends with end module name. On its own it does nothing: it is a container that a program or another module can use.
A program brings it in with a use statement at the top, before implicit none. Every public name in the module then behaves as if it had been declared in the program, with the compiler knowing the exact argument list of each procedure.
That last part is the real reason modules exist. A procedure compiled separately, without an interface, is called on trust: pass the wrong number of arguments and the program compiles and crashes. A procedure in a module carries its interface with it, so mistakes are compile errors.
use, and only
use scores imports everything public in the module. use scores, only: total, mean, pass_mark imports exactly those names and nothing else. The second form is longer and better: a reader can see where each name comes from without opening another file, and a name added to the module later cannot quietly collide with one of yours.
Constants travel the same way. real, parameter :: pass_mark = 60.0 in the module is a name with a value that cannot be changed, visible to every program that uses it. One place to change the pass mark is the point of putting it there rather than in three programs.
use scores, only: total => sum_scores gives the module’s sum_scores the local name total, which is how a module with a common name avoids colliding with a variable in the program. The left side is the name the program will use and the right side is the name in the module; reading it backwards is a common mistake.
One file here, several in a real project
This site compiles a single main.f90, so the module sits at the top of that file and the program that uses it comes after. Order matters: the module has to be defined before the compiler reaches the use.
In a real project each module lives in its own .f90 file and is compiled first, producing an .mod file that later compilations read for the interface. On the command line that means the module file comes before the program: gfortran scores.f90 main.f90. A build system earns its place by getting that order right once there are more than a couple of modules.
A .mod file is generated by the compiler and must be rebuilt whenever the module changes. A build that reuses an old one can compile a call against a stale interface and fail in a way that makes no sense from the source. When a module change produces impossible errors, delete the .mod files and build again.
A module and its user
module scores
implicit none
real, parameter :: pass_mark = 60.0
contains
real function mean(values)
integer, intent(in) :: values(:)
mean = real(sum(values)) / size(values)
end function mean
end module scores
program report
use scores, only: mean, pass_mark
implicit none
integer :: xs(3)
xs = [50, 60, 70]
print *, mean(xs), pass_mark
end program reportWhat a module hides and what it shares
A module has a default visibility, and it is public. Every name declared before contains is visible to a program that uses the module, including helper procedures you meant to keep internal. Put private on a line of its own near the top and then public :: total, mean for the names that are the module’s actual interface; the rest become internal, and you can change them without breaking a caller.
Module variables are shared state with an implicit save. A variable declared in the module keeps its value between calls and is seen by every procedure that uses the module, which is useful for a cached table and dangerous for a counter that two procedures both update. Constants are the safe case: real, parameter :: pass_mark = 60.0 is a value with a name, and putting it in the module means one place to change it.
Three module habits save a debugging session: give the module its own implicit none, because it does not inherit the program’s; mark helpers private before they become part of the interface by accident; and remember that a module variable is shared and keeps its value, so two procedures can silently edit the same number. A module is a small library, and its public names are a promise.
Try these next
- Add
privateto the scores module and apublic ::line for the two functions. - Add a module variable that counts calls to
mean, and print it after three calls. - Move
pass_markinto the module and change it in one place.
One definition, two users
Run it, then change pass_mark to 50.0 and notice that the program did not change at all. Then add a `max_score` function to the module and call it from the program.
A private library with two public names
Run it and check the two answers. Then make `pi` public and print it from the program, and try to call a procedure that is not in the `only` list.
The use statement comes before implicit none, and the module comes before the program that uses it. Both mistakes produce errors that point at the wrong line, so check the order first when a module will not compile.
Check what you learned
One question at a time. A wrong answer explains itself — take another go.
Part 1 of 5
Where does the use statement belong in a program?
