Resumen de la participación de los actores

interface body to external procedure .

interface body to external procedure .

interface body to external procedure .

. .

END INTERFACE or alternatively

INTERFACE generic-specification .

interface body to external procedure

.

interface body to external procedure MODULE PROCEDURE proc, proc, … .

MODULE PROCEDURE proc, proc, . . . .

. .

END INTERFACE

In the former case, the interface simply contains “interface bodies” for an arbitrary number of external procedures that are supplied in any order. Each interface body is a set of declarative statements associated with a particular function or subroutine:

FUNCTION/SUBROUTINE statement

USE statements, if relevant to characteristics of arguments (and function result)

Type Declaration Statements for arguments (and function result)

END FUNCTION/SUBROUTINE statement

In the second form of interface block, a generic-specification follows the keyword INTERFACE. The generic-specification may refer to the definition of an operator (Section 8.9) or to the setting-up of a generic name for several related procedures (Section 11.8) or to a defined assignment (Section 12.10). When there is a generic-specification, the external procedures represented by the interface bodies and the module procedures listed in the MODULE PROCEDURE statements must all be connected in that they will be different “specific” procedures corresponding to one “generic” form of invocation.

An external procedure always needs an explicit interface within any subprogram that calls it if any of the following is true:

1. the procedure is ELEMENTAL (Section 11.3);

2. there are OPTIONAL dummy arguments (Section 11.7);

3. a dummy argument is an assumed-shape array (Section 8.6), a pointer or a target (Chapter 13);

4. the procedure is a function with an array or pointer as its result;

5. the procedure is a function whose value is a character string of "automatic" length, i.e. a non-constant (and non-assumed) length given by a specification expression (Section 11.9).

Even if Conditions 1–5 do not apply, an external procedure needs an explicit interface to a particular subprogram if it is called from that subprogram under any of the following circumstances:

1. when it is called with an argument keyword (Section 11.6);

2. when it is a subroutine invoked through a defined assignment (Section 12.10);

3. when it is a function invoked through a defined operator (Section 8.9).

4. when it is invoked by a generic name rather than specific one (Section 11.8); or

5. when it is a PURE procedure (Section 11.2), and it is being called in circumstances that require it to be PURE (for example, if it is being called from another PURE procedure).

Even if it is not strictly necessary to provide an interface to a procedure, it is not an error to do so and it is wise to provide interfaces liberally rather than depend on remembering the rules listed above. Some authorities on Fortran believe that explicit interfaces should always be provided to all procedures to improve program reliability, since a high proportion of programming errors arise from incorrect data association when procedures are called.

11.2

PURE procedures (Fortran 95 feature not in Fortran 90) A “pure” procedure is one that has no side-effects.

A pure function calculates and returns its value, but its argument or arguments must have INTENT (IN) and may not be changed within the function. A pure subroutine, however, may have arguments of INTENT (OUT) or (IN OUT) , as well as INTENT (IN) . In both pure functions and pure subroutines, local variables

—those whose scope is limited to the procedure itself—may be manipulated, but not variables of wider scope linked with the procedure by the USE association of a module or by host association.

A pure procedure may not read or write external files or carry out other i/o operations. Internal files may be written or read, but any that are written must have names local to the procedure so that no information may leak out. If a pure procedure makes reference to another procedure, that also must be pure. Otherwise, we could have an illogical situation where the procedure referred to could generate side-effects on the

“pure” procedure’s behalf.

Intrinsic functions are always pure, and can therefore be referred to from within any other pure procedure. Intrinsic subroutines are pure if they are elemental (e.g. MVBITS) but not otherwise.

A pure procedure is declared as such in its header statement by prefixing the keyword FUNCTION or SUBROUTINE with PURE, e.g.

PURE FUNCTION Quintessence (x) REAL :: Quintessence

REAL, INTENT(IN) :: x

. . .

END FUNCTION Quintessence

The INTENT specification is compulsory: all the arguments of a pure procedure must have declared INTENT, except in the unusual cases of arguments that are dummy procedures (Chapter 14) or pointers (Chapter 13). For the first line, the syntax

REAL PURE FUNCTION Quintessence (x) or

PURE REAL FUNCTION Quintessence (x)

would also be allowed but neither is recommended. Finally, the END FUNCTION statement does not include the word PURE but the word FUNCTION is not optional and must be there.

If a pure procedure has a dummy procedure name as an argument (Chapter 14), the corresponding actual argument must be pure and it must either be an intrinsic procedure or it must have an explicit interface in the pure procedure where (through its dummy name) it is being referenced.

Pure procedures may not be recursive (Section 11.4 below). Moreover, local variables within a pure procedure may not be saved from one call to the next, so the SAVE attribute is not allowed, and neither may their values be initialized. Also, pure procedures may not STOP!

A pure procedure requires an explicit interface if a reference to it appears in a context that requires the procedure to be pure. An example would be if the procedure is called from within another pure procedure.

It would be fair to ask why the programmer should declare any procedure to be PURE, since to do so involves a number of restrictions and appears to give no additional functionality. Any program with pure procedures would, apparently, be unaffected if the keyword PURE were deleted wherever it occurs. So why bother?

Actually, there are two contexts in which procedures have to be pure, namely in Fortran 95 specification expressions (Section 11.9) and in the FORALL construct (Section 6.5). Specification expressions are a minor issue and, by themselves, would not justify the introduction of the PURE keyword and the rules associated with it. The real reason for specifying PURE procedures is shown by FORALL and is to do with the spread of parallel-processing systems that can take advantage of the fact that multiple calls to pure procedures may be made in any order or simultaneously. Purity, therefore, may not make the programmer’s job easier, but in principle it can facilitate greater program efficiency and speed of execution, particularly when the program is to be run on an advanced parallel-processing system.

11.3

ELEMENTAL procedures (Fortran 95 feature not in Fortran 90)

Many of Fortran’s intrinsic procedures, both in Fortran 95 and in Fortran 90, are “elemental”. In Fortran 95 it is also possible for users to write elemental procedures of their own. An elemental procedure is specified as such by having the keyword ELEMENTAL in place of PURE, e.g.

ELEMENTAL FUNCTION Quintessence (x)

It is never necessary to specify a procedure to be both ELEMENTAL and PURE because all elemental procedures are also pure. In fact, of the prefixes ELEMENTAL, PURE, and RECURSIVE, no more than one can ever be used at once. All the constraints on pure procedures, mentioned in the previous section, apply also to elemental procedures. However, to be elemental involves additional restrictions.

Speaking loosely, the point of an elemental procedure is that it is defined in terms of scalar dummy arguments but can be referenced either with a scalar or with an array as the actual argument; if with an array, the effect is as if the procedure were called repeatedly for each element of the array. This allows whole-array operations to be written compactly and it can simplify the implementation of parallel processing on machines capable of it.

Within an elemental procedure, all the dummy arguments must be scalars and may not be pointers or procedure names. If we have an elemental function, its result must be treated as a scalar within the function.

However an elemental function’s actual argument, by which it is called from elsewhere, may be an array, in which case the result is also an array of the same shape.

An elemental procedure may be a subroutine rather than a function. When an elemental subroutine is called, either

1. all the actual arguments must be scalars, or

2. all the actual arguments whose INTENT is OUT or IN OUT may be arrays, but they must have the same shape; and those whose INTENT is IN must either have the same shape again or must be scalars.

An example may help to clarify this:

ELEMENTAL SUBROUTINE Matrix_Diff_Square (a, b, q, z) REAL, INTENT (IN) :: a, b, q

REAL, INTENT (OUT) :: z

! Each element of z is to be set equal to the square ! of the difference between the corresponding elements ! of a and b, divided by q.

z = ((a–b)**2)/q

END SUBROUTINE Matrix_Diff_Square

This could be invoked elsewhere by code such as:

REAL :: d(10, 10), e(10, 10), f(10, 10), g = 10000.0 .

. .

CALL Matrix_Diff_Square (d, e, g, f)

In this example, three actual arguments are arrays and, following the rules, they have the same shape. One actual argument (g) is a scalar but in theory it could equally well have been an array as long as its shape was the same (10, 10) as the other arguments. There is just one circumstance - when a dummy argument is used in a specification expression (Section 11.9) - in which the actual argument is restricted to being a scalar.

When one is working with user-defined derived data types (Chapter 12), defined assignments may be elemental. In fact, if the defined assignment is to be used in a WHERE construct, it must be elemental.

Every elemental procedure requires an explicit interface in a program unit that invokes it.

11.4

RECURSIVE procedures

Normally a procedure may not invoke itself, either directly or indirectly. In some circumstances, though, it can be convenient to let this happen, and it is made possible by putting the keyword RECURSIVE before the procedure’s name in the first line of the procedure. This can be applied both to functions and to subroutines, but in the case of a function an extension has to be made to the syntax of the FUNCTION statement: if, for example, a function called Iris is to be made recursive, its first line could be

RECURSIVE FUNCTION Iris (juniper) RESULT (berry)

The meaning of RESULT (berry) is explained below. Subroutines are simpler, just requiring the keyword RECURSIVE as in

RECURSIVE SUBROUTINE Metamorphosis (jekyll, hyde)

How can recursive procedures be used? An example is this subroutine to put a sequence of characters into alphabetical order:

RECURSIVE SUBROUTINE Order (caps) CHARACTER(1):: caps(:), store

LOGICAL :: disorder disorder = .FALSE.