Chapter 18
Essentials of Essentials of Fortran-90/95/2003
Archaic Statements

Math 60 -- D. C. Smolarski, S.J.
Santa Clara University, Department of Mathematics and Computer Science

[Return to Math 60 Homepage | Return to Brief Contents Page]
[Return to Full Contents Page]

Contents

18.1 Overview

The introduction into Fortran-90/95/2003 of various new statements and features has rendered some older Fortran structures, for all practical purposes, obsolete. In some cases, certain statements or features have been officially designated for planned obsolescence, which means that future Fortran compilers may, in fact, not recognize the statements and programmers are advised to rewrite older code to avoid their use (cf. Chapter 19).

This chapter gives a brief overview of the more significant of the older structures so that programmers may understand the function of these structures, if they should, by chance, be working with older Fortran code.

Note that certain of the statements contained below are "specification" statements. Also note that there is an appropriate order to these and other specification statements (some of which have already been seen in previous sections, such as the USE statement, the TYPE definition statement, the type declaration statements, e.g., REAL, INTEGER). The chart in section 18.11 summarizes the preferred order for statements currently in use as well as those considered archaic.

18.2 GO TOs

There are three types of GO TO statements in Fortran: unconditional GO TOs, computed GO TOs, and assigned GO TOs. All forms have been rendered virtually useless because of the introduction of the block IF statement, the SELECT CASE structure, and the EXIT and CYCLE statements for use within DO loops. We briefly mention the unconditional GO TO here for reference, in order to help programmers understand older Fortran code. Information on computed GO TOs and assigned GO TOs may be found in a complete FORTRAN-77 reference book.

The form of the unconditional GO TO is as follows: 

	GO TO n
where n is an integer number which is used as the statement label of an executable statement (including a CONTINUE). (Thus, FORMAT statements and the END statement, neither being an executable statement, are excluded). The statement transferred to must be in the same program segment (i.e., it cannot be in a different subroutine or function).

The program flow is transferred unconditionally to statement number n and continues from there. This is not the same as a subroutine call which returns to the line after the point from which it is called. Once control is transferred to another statement by means of a GO TO, the only way control can get back to the point of the program immediately after the GO TO in question is by means of another GO TO!

For example, 

	   PROGRAM SAM7
	   WRITE(6,*) 'Point 1'
	   GO TO 1
	2  WRITE(6,*) 'Point 2'
	   STOP
	1  WRITE(6,*) 'Point 3'
	   GO TO 2
	   END
will cause the output 
	Point 1
	Point 3
	Point 2
because of the leap-frog program flow.

As this example shows, GO TOs can also lead to messy and unreadable code. Code containing many GO TOs is often called `spaghetti code,' since frequently its flow is about as apparent as a bowl of spaghetti (also see the example given earlier in section 16.2). With Fortran-90/95/2003 structures, there is virtually no need to use GO TOs.

18.3 Arithmetic IF

This is the oldest form of decision statement in Fortran and uses an arithmetic expression on which to base a decision.

Its form is as follows: 

	IF ( arithmetic expression ) n1, n2, n3
The operation of this IF is as follows: If the arithmetic expression evaluates to a negative number, control is transferred to statement labeled n1. If the arithmetic expression evaluates to zero, control is transferred to statement labeled n2. If the arithmetic expression evaluates to a positive number, control is transferred to statement labeled n3.

This form of the IF is equivalent to three GO TOs and the same problems that plagued the use of GO TOs also affects the use of this version of the IF. Thus it should not be used, and one the other options available in Fortran-90/95/2003 should be used in its place.

18.4 Two Value Logical IF

The two value IF was commonly used in FORTRAN IV to implement what a block IF now does in Fortran-90/95/2003 but in a less "structured" way. Its form is: 
	IF (A .LE. B) n1, n2
If the condition evaluates to .TRUE. then control is transferred to statement label n1. If, however, the condition evaluates to .FALSE. then control is transferred to statement label n2. As with the arithmetic IF mentioned above, this is equivalent to two GO TOs, and as such, any statement immediately following this IF must have a statement label. This also should no longer be used, since the `block IF' structure provides equivalent program control with better readability.

18.5 DATA Statements

A DATA statement is used to initialize variables with values. Since Fortran-90/95/2003 permits variables to be initialized when being declared (cf. section 2.4 for scalar variables and section 8.2 for arrays), the use of a separate DATA statement merely to initialize already declared variables is unnecessary, and is considered a poor programming practice. Thus, the use of DATA statements is discouraged.

A DATA statement normally appears before any executable statement (after the other declarations statements) and is executed once (even if it appears in a subprogram which is called often). In the DATA statement, one lists the variables to be initialized followed by the initial value (for each variable) enclosed in slash bars. Several variables (and values) are separated by commas. Arrays may be listed without any subscript if the entire array is to be initialized. The following provides three examples of using DATA statements:
1) 

	DATA A/1.0/,I/2/
2) 
	REAL B(5)
	DATA B/1.0,2.0,3.0,4.0,5.0/
3) 
	DATA I,J,K/3*0/
The second example shows that the same process takes place for arrays in DATA statements as happens in a READ or WRITE statement in that, if no subscript is given, Fortran "expands" the array named to include all the elements of the array. Thus, since there are five elements in array B, five values must be given within the slash lines. The third example shows that it is possible to "multiply" a value within the slash lines (by prepending an integer constant and the * symbol before a value) when the same value will be assigned to several variables.

18.6 COMMON

A COMMON statement provides a way to identify variables that will be shared (or held "in common") by different program segments. This approximated in Fortran the concept of global variables found in other languages and was a way around the Fortran rule that all variables are local to the program segment in which they are declared. The goal of the COMMON statement is now accomplished by Fortran-90/95/2003 modules (cf. Chapter 9) and, thus, modules should be used, rather than COMMON statements, in contemporary programs.

The keyword COMMON is followed by the names of the variables one wishes to be held in common (separated by commas). This must be done in each subprogram which is to use these variables.

For example, 

	COMMON A,B,C
NOTES:

  1. The variables listed should already be declared (as scalars or arrays) in type declaration statements which must precede the COMMON statements.

  2. The order of identifiers in a COMMON statement is all-important. In this sense, the COMMON statement is very similar to the way the argument list works between a calling segment and the subprogram being called--the first names are associated with each other, then the second names, and so on. For example, if, the main program had 
    	COMMON A,B,C
    and a subroutine had 
    	COMMON B,C,A
    then, what was called A in the main program would be called B in the subroutine and so on.

  3. A COMMON statement must be included in each subprogram that needs to use the variables listed. Moreover, each variable listed in a COMMON must be declared the same way in each subprogram where it is found. If certain variables are declared as arrays in one segment, they must also be declared as arrays everywhere, even if they are never used in a given subprogram.

Since a COMMON statement reserves consecutive memory locations in each program segment in which it is included, it is possible to use creative techniques to turn, for example, three arrays of one size into one array of three times the size merely by declaring arrays appropriately in the different segments and including different names in the individual COMMON statements. Such "tricks" are difficult to read and interpret and thus to debug, and, for these reasons, are discouraged.

One can also give a name to any COMMON area, allowing the possibility of having more than one COMMON area. One such "named" COMMON area might be used between the main program and one subroutine and another COMMON area between the main program and a different subroutine. To give a COMMON area a name, one encloses the chosen name between slashes after the word COMMON. For example, 

	COMMON /EXAM/ A,B,C
	COMMON /GRADE/ G,F,H
Variables may appear in only one named COMMON block.

Mixing character and numeric types in a COMMON statement on most systems leads to errors. Thus, if one is using character variables and wishes to place them in COMMON, one should use several named COMMON areas and keep all character variables in one area and numeric variables in another.

18.7 BLOCK DATA Subprograms

Variables in a named COMMON block may be initialized only by means of a BLOCK DATA subprogram. This subprogram only contains the variables to be initialized and a DATA statement for the initialization. A name for the BLOCK DATA unit (placed immediately after the keywords BLOCK DATA) is optional. For example, 
	BLOCK DATA INIT1
	REAL GRADES(20)
	COMMON /SECT1/ GRADES
	DATA GRADES/20*1.0/
	END
NOTES:

  1. A RETURN statement is not used.

  2. Named COMMON blocks must be fully specified, even when only some of its entries are initialized.

18.8 EQUIVALENCE

The EQUIVALENCE statement may be used to associate two different identifiers to the same memory location in the same program segment. The result is that one identifier is an alias for the other. The general form is 
	EQUIVALENCE (A,B)
This statement will make A and B equivalent names for the same memory location. It is also permitted to equivalence arrays, even of different sizes, by equivalencing the "starting" elements in two arrays. For example, 
	REAL A(10),B(5)
	EQUIVALENCE (A(3),B(1))
This will make A(3) and B(1) equivalent names for the same memory location, and also A(4) and B(2), and A(5) and B(3), and A(6) and B(4), and finally A(7) and B(5).

The EQUIVALENCE statement was of more usefulness when programming was done via cards, and it could happen that one programmer used one identifier for variable and another programmer used a different identifier for the same concept. Instead of retyping a great number of cards, two different identifiers were made equivalent via this statement.

Since contemporary programs are written on electronic files with the ability to rename identifiers globally in a file, there is less need to use EQUIVALENCE statements to rename variables. In addition, the use of pointers also creates the functional equivalence of making two identifiers equivalent (cf. Chapter 17). Thus, there is no reason to use this statement, given the other features of Fortran-90/95/2003.

18.9 PARAMETER Statements

The PARAMETER statement may be used to assign a constant value to an identifier. After the keyword PARAMETER, one assigns a value to a parameter name (with an equals sign) and encloses this in parentheses. The parameter names should be declared in a type statement prior to the PARAMETER statement, so that each identifier matches in type the value received. More than one assignment can be included in the set of parentheses, if separated by commas, and arithmetic expressions may be included. For example, 
	PARAMETER (PI=3.1415926, THIRD=1.0/3.0)
Since identifiers may be designated as constant parameters in a type declaration statement in Fortran-90/95/2003 by included "PARAMETER" as an attribute (cf. section 2.3), the use of a separate PARAMETER statement is not recommended.

18.10 DIMENSION Statements

The sole purpose of a DIMENSION statement is to indicate the dimension of an array which has been declared independently in a type specification statement (or given a default type). The array variable name is listed and the size of the array is indicated by enclosing the number in parentheses. For example, if one wishes B to be a real array of size 20 (with first subscript equal to 1), then one can write 
	REAL B
	DIMENSION B(20)
NOTE: Most authors suggest that the DIMENSION statement should never be used by contemporary programmers. Array dimensions should be indicated either by the DIMENSION attribute in the type declaration statement, or by indicating the dimension after the array identifier itself (cf. section 8.2).

18.11 Order of Specification Statements

All the specification statements normally come together at the beginning of a program segment, but they have a relative order. The following is the preferred order. 
    [PROGRAM, FUNCTION, SUBROUTINE, or BLOCK DATA header line]
        [USE module-name]
	IMPLICIT NONE (or other IMPLICIT type statement)
	PARAMETER 
	derived TYPE definition
	type declarations (INTEGER, REAL, LOGICAL, CHARACTER,
		DOUBLE PRECISION, derived TYPE--in any order)
	DIMENSION
	COMMON
	EQUIVALENCE
	DATA
	one-line function designators
    [executable statements]
    [END]
NOTES:

  1. Comments may come anywhere before the END (including before and after the header).

  2. FORMAT and ENTRY (cf. section 10.10) statements may appear anywhere between the header (or USE statement, if included) and the END.

  3. In Fortran-90, DATA statements may actually appear anywhere between IMPLICIT statements and the END, including among executable statements, but the variables listed are only initialized once. Their location in any place other than at the beginning of the program makes little sense, and thus, Fortran-95 prohibits their inclusion after the first executable statement.

  4. PARAMETER statements may actually appear anywhere between the header and the one-line function designators. Nevertheless, parameters must be defined before use in other specification statements, and the identifiers should be declared as to correct type before receiving a value. 
__________________________________________________________________
| 		    |  PROGRAM, FUNCTION, SUBROUTINE,	         |
|		    |  [BLOCK DATA] or MODULE  statements	 |
|		    |____________________________________________|
|		    |             USE  statements       	 |
|		    |____________________________________________|
|		    |	         |  IMPLICIT NONE  statement	 |
|		    |	         |_______________________________|
|		    | FORMAT     | PARAMETER  | IMPLICIT   	 |
|Comment	    | and        | statements | statements 	 |
|lines		    | ENTRY      |____________|__________________|
|		    | statements |	      | other	    	 |
|		    |	         | PARAMETER  | specification	 |
|		    |	         |   and      | statements*	 |
|		    |	         |            |__________________|
|		    |	         | DATA	      | statement	 |
|		    |	         | statements | function	 |
|		    |	         |	      | statements       |
|		    |	         |____________|__________________|
|		    |	         |	   executable   	 |
|		    |	         |	   statements   	 |
|___________________|____________|_______________________________|
|                CONTAINS  statement				 |
|________________________________________________________________|
|             Internal or Module Subprograms			 |
|________________________________________________________________|
|                  END statement				 |
|________________________________________________________________|
*These include Type Declaration Statements for variables, Derived-Type Definitions for new variable types, Interface Blocks, and Other Specification Statements as noted before the chart.

This page is maintained by Dennis C. Smolarski, S.J. dsmolarski@math.scu.edu
© Copyright 1999-2005 Dennis C. Smolarski, S.J., All rights reserved.
Last changed: 28 June 2005.