DCL: MATH1: Summary: FORTRAN77 Standard
One of the fundamental concepts of the FORTRAN standard is the concept of "undefined." This is one of the most important concept, yet one of the most difficult to comprehend. Anyone who has studied FORTRAN has probably encountered the following sentence in a grammar book and has been puzzled by it.
To understand this rather puzzling sentence, you need to consider who the documents of FORTRAN standard were written for. The FORTRAN standard is a document written for us programmers as well as for those who create the FORTRAN compilers. Therefore, this sentence was written so that it can be translated in two ways. For those who create compilers, the above sentence translates to
If this sentence is taken as a message from "those who created" the compiler to "those who use" compilers, many will no doubt be indignant that "the creator should be so irresponsible that he doesn't know what happens!" Especially, one gets such an impression upon reading the grammar book that comes with the compiler. But keep in mind that a FORTRAN grammar book contains
The opposite of "undefined" is "defined," a state in which the value is guaranteed by the standard. According to standard, variables that can be inquired in programs are limited to those "defined." A variable becomes "undefined" in the following cases.
This is the most easy-to-understand case of "undefined." If a value is not assigned to a variable, obviously, there is no knowing what value the variable takes.
Some compilers initialize all variables (normally by assigning 0). In FORTRAN standard, the variable is "undefined," (hence, what to do is left up to the compiler), so such compilers are not going against the FORTRAN standard. However, this state is not guaranteed by the standard, and is a type of "dialect," so programs should not be written with this precondition when considerations are given to future applications of the programs in different compilers.
When you want to assign a value to a variable from the start, use the DATA statement. See example below.
Variables used in subroutines become, with a few exceptions, "undefined" once the execution of the subroutine is over.
This may be a bit difficult to understand, but it means that when the same subroutine is called twice, in the second call, you cannot inquire on a variable that has been assigned a value in the first call, since there is no guarantee that the value has been saved.
See the following program, for example.
*------------ main program ----------- DO 100 I=1, 100 CALL BEAT 100 CONTINUE END *-------------------------------- SUBROUTINE BEAT DATA N /0/ SAVE N=N+1 IF(N.EQ.10) THEN WRITE(6,*) ' I hate you !' N=0 ENDIF ENDThis subroutine BEAT remembers the number of times (N) that is was called, and prints a message when it has been called 10 times.
Variable N is defined and given the value 0 using a DATA statement before BEAT is called. Every time BEAT is called, 1 is added to variable N. However, if it were not for the SAVE statement in line 9, the N again becomes undefined after the END statement in line 16, according to the FORTRAN standard.
The SAVE statement is a declaration ordering the program to keep the value of the variable in the subroutine after the end of execution. In a program such as this, in which the value of variable N must be kept to the next call in order for it to operate properly, the SAVE statement must always be included.
Depending on the compiler (or in most compilers), local variables in the subroutine are kept, but this also, is a "dialect.".
However, variables specified using the DATA statement do not become "undefined" even after the RETURN or END statement has been executed, unless the value is overwritten.
The GLpGET/GLpSET of the DCL can act as a bulletin board due to the DATA and SAVE statements. (See Section 1.5.4.)
When the SAVE statement is specified, the executed file size usually increases, but in many cases, the execution speed increases.
When different types of variables are associated using the EQUIVALENCE statement and one of the variables is defined, the other becomes undefined. For example, in the following program,
INTEGER IX REAL RX EQUIVALENCE (IX, RX) RX = 1. WRITE(6,*) IX ENDwhen the floating-point variable RX is assigned, the value of the integer variable IX becomes undefined. Therefore, the WRITE statement inquiring on an undefined variable is grammatically incorrect.
In this case, though, IX has a "certain value." . However, since the expression format for integers and floating-point numbers are not the same for different compilers, what this "certain value" is cannot be predicted from FORTRAN standard. Hence, it is "undefined."
Therefore, the result of this program cannot be predicted from grammar, but it will, nonetheless. usually operate properly and output a "certain value." (See Section 1.5.4)