When a program is more than a few hundred lines long, it gets hard to follow.
Fortran code that solves real problems often has tens of thousands of
lines. The only way to handle such extensive code, is to use a *modular*
approach and split the program into many separate smaller units called
*subprograms*.

A subprogram is a small piece of code that solves a well-defined subproblem. In a large program, one often has to solve the same subproblems with many different data. Instead of replicating code, these tasks should be solved by subprograms. The same subprogram can be invoked many times with different input data.

Fortran has two different types of subprograms, called *functions*
and *subroutines*.

Fortran functions are quite similar to mathematical functions: They both
take a set of input arguments (parameters) and return a value of some type.
In the preceding discussion we talked about *user defined* subprograms.
FORTRAN 77 also has some *intrinsic* (built-in) functions.

A simple example illustrates how to use a function:

x = cos(pi/3.0)

Here `cos` is the cosine function, so `x` will be assigned
the value 0.5 (if `pi` has been correctly defined; Fortran 77 has
no built-in constants). There are many intrinsic functions in Fortran 77.
Some of the most common are:

absabsolute valueminminimum valuemaxmaximum valuesqrtsquare rootsinsinecoscosinetantangentatanarctangentexpexponential (natural)loglogarithm (natural)

In general, a function always has a *type*. Most of the built-in
functions mentioned above, however, are *generic*. So in the example
above, `pi` and `x` could be either of type
`real` or `double precision`. The compiler would check the types
and use the correct version of `cos` (real or double precision).
Unfortunately, Fortran is not really a *polymorphic* language so in
general you have to be careful to match the types of your variables and your
functions.

Now we turn to the user-written functions. Consider the following problem:
A meteorologist has studied the precipitation levels in a particular area and
has come up with a model *r(m,t)* where *r* is the amount of rain,
*m* is the month, and *t* is a scalar parameter that depends on the
location. Given the formula for *r* and the value of *t*, compute the
annual rainfall.

The obvious way to solve the problem is to write a loop that runs over all
the months and sums up the values of *r*. Since computing the value of
*r* is an independent subproblem, it is convenient to implement it as a
function. The following main program can be used:

program rain real r, t, sum integer m read (*,*) t sum = 0.0 do 10 m = 1, 12 sum = sum + r(m, t) 10 continue write (*,*) 'Annual rainfall is ', sum, 'inches' stop end

Note that we have declared 'r' to be 'real' just as we would a variable.
In addition, the function *r* has to be defined as a Fortran function.
The formula the meteorologist came up with was:

r(m,t) = t/10 * (m**2 + 14*m + 46)if this is positiver(m,t) = 0otherwise

The corresponding Fortran function is;

real function r(m,t) integer m real t r = 0.1*t * (m**2 + 14*m + 46) if (r .LT. 0) r = 0.0 return end

We see that the structure of a function closely resembles that of the main program. The main differences are:

- Functions have a type. This type must also be declared in the calling program.
- The return value should be stored in a variable with the same name as the function.
- Functions are terminated by the
*return*statement instead of*stop*.

To sum up, the general syntax of a FORTRAN 77 function is:

typefunctionname (list-of-variables)declarationsstatementsreturn end

The function has to be declared with the correct type in the calling program unit. If you use a function which has not been declared, Fortran will try to use the same implicit typing used for variables, probably getting it wrong. The function is called by simply using the function name and listing the parameters in parenthesis.

It should be noted that, strictly speaking, Fortran 77 doesn't permit recursion (functions which call themselves). However, it is not uncommon for a compiler to allow recursion.

A Fortran function can essentially only return one value. Often we want
to return two or more values (or sometimes none). For this purpose we
use the `subroutine` construct. The syntax is as follows:

subroutinename (list-of-arguments)declarationsstatementsreturn end

Note that subroutines have no type and consequently cannot be declared in the
calling program unit. They are also invoked differently than functions, using
the word *call* before their names and parameters.

We give an example of a very simple subroutine. The purpose of the subroutine is to swap two integers.

subroutine iswap (a, b) integer a, b c Local variables integer tmp tmp = a a = b b = tmp return end

Note that there are two blocks of variable declarations here. First, we
declare the input/output parameters, i.e. the variables that are common
to both the caller and the callee. Afterwards, we declare the *local
variables*, i.e. the variables that can only be used within this subprogram.
We can use the same variable names in different subprograms and the compiler
will know that they are different variables that just happen to have the
same names.

FORTRAN 77 uses the so-called *call-by-reference* paradigm. This means
that instead of just passing the values of the function/subroutine arguments
(*call-by-value*), the memory address of the arguments (pointers)
are passed instead. A small example should show the difference:

program callex integer m, n c m = 1 n = 2 call iswap(m, n) write(*,*) m, n stop end

The output from this program is "2 1", just as one would expect. However, if FORTRAN 77 had been using call-by-value then the output would have been "1 2", i.e. the variables m and n were unchanged! The reason for this is that only the values of m and n had been copied to the subroutine iswap, and even if a and b were swapped inside the subroutine the new values would not have been passed back to the main program.

In the above example, call-by-reference was exactly what we wanted.
But you have to be careful about this when writing Fortran code, because
it is easy to introduce undesired *side effects*. For example, sometimes
it is tempting to use an input parameter in a subprogram as a local variable
and change its value. Since the new value will then propagate back to the
calling program with an unexpected value, you should *never* do this unless
(like our iswap subroutine) the change is part of the purpose of the
subroutine.

We will come back to this issue in a later section on passing arrays as arguments (parameters).

*Copyright © 1995-7 by Stanford University. All rights reserved.*