This requires that parentheses enclosing more than one I/O list item must mark an implied DO-loop. The restriction was imposed to eliminate potential syntactic ambiguities introduced by complex constants in list-directed output lists. As all the parentheses referred to are redundant, a program can be made conforming with this standard by deleting redundant parentheses enclosing more than one list item in an I/O list.
'
When you read this standard, it is important to keep its point of view in mind. The standard is written from the point of view of a programmer using the language, and not from the point of view of the implementation of a processor. This point of view affects the way you should interpret the standard. For example, in 3.3 the assertion is made:
This means that if a programmer writes a longer statement, his program is not standard conforming. Therefore, it will get different treatment on different processors. Some processors will accept the program, and some will not. Some may even seemingly accept the program but process it incorrectly. The assertion means that all standard-conforming processors must accept statements up to 1320 characters long. That is the only inference about a standard-conforming processor that can be made from the assertion.
The assertion does not mean that a standard-conforming processor is prohibited from accepting longer statements. Accepting longer statements would be an extension.
The assertion does not mean that a standard-conforming processor must diagnose statements longer than 1320 characters, although it may do so.
In general, a standard-conforming processor is one that accepts all standard-conforming programs and processes them according to the rules of this standard. Thus, the specification of a standard-conforming processor must be inferred from this document.
In some places, explicit prohibitions or restrictions are stated, such as the above statement-length restriction. Such assertions restrict what programmers can write in standard-conforming programs and have no more weight in the standard than an omitted feature. For example, there is no mention anywhere in the standard of double precision integers. Because it is omitted, programmers must not use this feature in standard-conforming programs. A standard-conforming processor may or may not provide it or diagnose its use. Thus, an explicit prohibition (such as statements longer than 1320 characters) and an omission (such as double precision integers) are equivalent in this standard.
FORTRAN Other_Languages
Variable Simple Variable
Array Element Subscripted Variable
Subscript Expression Subscript
Subscript (none)
Dummy Argument Formal Argument, Formal
Parameter
Actual Argument Actual Parameter
In particular, the FORTRAN terms "subscript" and
"subscript expression" should be studied
carefully by readers who are unfamiliar with this standard (
5.4).
The term "symbolic name" is frequently shortened to "name" throughout the standard.
When a continuation line follows a comment line, the continuation line is part of the current statement; it is not a continuation of the comment line. A comment line is not part of a statement.
The standard does not restrict the number of consecutive comment lines. The limit of 19 continuation lines permitted for a statement should not be construed as being a limitation on the number of consecutive comment lines.
There are 99999 unique statement labels and a processor must accept 99999 as a statement label. However, a processor may have an implementation limit on the total number of unique statement labels in one program unit ( 3.4).
Blanks and leading zeros are not significant in distinguishing between statement labels. For example, 123, 1 23, and 0123 are all forms of the same statement label.
ANSI X3.9-1966 used the term "constant" to mean an unsigned constant. This standard uses the term "constant" to have its more normal meaning of an optionally signed constant when describing arithmetic constants. The term "unsigned constant" is used wherever a leading sign is not permitted on an arithmetic constant.
A character constant is a representation of a character value. The delimiting apostrophes are part of the representation but not part of the value; double apostrophes are used to represent a single embedded apostrophe. For example:
____________________________
| | |
| Character | Character|
|___Constant____|____Value__|
| | |
| 'CAT' | CAT |
| 'ISN''T' | ISN'T |
| '''ISN''''T'''| 'ISN''T' |
|_______________|___________|
Note that the value of the character constant '''ISN''''T''' is a representation of another character constant.
Some programs that used an extension to ANSI X3.9-1966 that permitted a Hollerith constant delimited by apostrophes instead of the nH form do not conform to this standard.
ANSI X3.9-1966 permitted two- and three-dimensional arrays to have a one-dimensional subscript in an EQUIVALENCE statement. The following table can be used to convert a one-dimensional subscript to the corresponding multidimensional subscript:
___________________________________________________ | | | | | | n| Dimension | Subscript| Subscript | |__|____________|____Value__|______________________| | | | | | | 1| (d ) | s | (s) | |__|_______1____|___________|______________________| | | | | | | 2| (d1,d2) | s | (1+MOD(s-1,d1), | |__|____________|___________|___1+(s-1)/d1_________| | | | | | | 3| (d ,d ,d )| s | (1+MOD(s-1,d ), | | | 1 2 3 | | 1+MOD((s-1)1d ,d ),| | | | | 1+(s-1)/(d *d1))2 | |__|____________|___________|_____________1__2_____|
Each expression in the last column of the table is evaluated according to the rules for integer expressions.
A processor that allows additional intrinsic functions should allow their names to appear in an INTRINSIC statement.
As an extension to ANSI X3.9-1966, many processors permitted the retention of certain values at the completion of execution of a subprogram, such as local variables and arrays, initially defined data that had been changed, and named common blocks not specified in the main program, whereas other processors prohibited the retention of such values. In ANSI X3.9-1966 such entities were undefined at the completion of execution of the subprogram, and therefore a standard-conforming program could not retain these values. The SAVE statement provides a facility for data retention.
Initially defined entities in a subprogram may become undefined at the execution of a RETURN or END statement if they are assigned any value, including their initial value, during the execution of the executable program (see 8.9 and 15.8.4).
IF (logical expr.) IF (arithmetic expr.) s ,s ,s
1 2 3
A processor is not required to evaluate the iteration count
in a DO-loop if the same effect is achieved without
evaluation.
However, the processor must allow
redefinition of variables and array elements that appear
after the equals in a DO statement during the execution of
the DO-loop without affecting the number of times the DO-loop
is executed and without affecting the value by which
the DO-variable is incremented.
If J1 > J2, ANSI X3.9-1966 does not allow execution of the following DO statement:
DO 100 J=J1,J2
Some processors that allowed such a case executed the range of the DO-loop once, whereas other processors did not execute the range of the DO-loop. This standard allows such a case and requires that the processor execute the range of the DO-loop zero times. The following change to the DO statement will require that the processor execute the range at least once:
DO 100 J=J1,MAX(J1,J2)
References to function procedures and subroutine procedures may appear within the range of a DO-loop or within an IF-block, ELSE IF-block, or ELSE-block. Execution of a function reference or a CALL statement is not considered a transfer of control in the program unit that contains the reference, except when control is returned to a statement identified by an alternate return specifier in a CALL statement. Execution of a RETURN or END statement in a referenced procedure, or execution of a transfer of control within a referenced procedure, is not considered a transfer of control in the program unit that contains the reference.
The CONTINUE statement is an executable statement that has no effect of itself. It can serve as an executable statement on which to place a statement label when no effect of execution is desired. For example, it can serve as the statement referred to by a GO TO statement or as& the terminal statement of a DO-loop. Although the CONTINUE statement has no effect of itself, it causes execution to continue with incrementation processing when it is the terminal statement of a DO-loop.
The standard does not define the term "accessible" in the STOP or PAUSE statement in order to allow a wide latitude in adapting to a processor environment. Some processors may use the n the PAUSE or STOP statement for documentation only. Other processors may display the n to the user or to the operator. In order not to confine its use, the meaning of "accessible" is purposely left vague.
An endfile record does not necessarily have any physical embodiment. The processor may use a record count or other means to register the position of the file at the time an ENDFILE statement is executed, so that it can take appropriate action when that position is again reached during a read operation. The endfile record, however it is implemented, is considered to exist for the BACKSPACE statement.
An internal file permits data to be transferred with conversion between internal storage areas using the READ and WRITE statements. This facility was implemented as an extension to ANSI X3.9-1966 on many processors as ENCODE and DECODE statements. Specifying the READ and WRITE statements to perform this process avoids such confusion as: "Is ENCODE like READ or is it like WRITE?"
This standard accommodates, but it does not require, file cataloging. To do this, several concepts are introduced.
In ANSI X3.9-1966 many properties were given to a unit that in this standard are given to the connection of a file to a unit. Also, additional properties are introduced.
Before any input/output can be performed on a file, it must be connected to a unit. The unit then serves as a designator for that file as long as it is connected. To be connected does not imply that "buffers" have or have not been allocated, that "file-control tables" have or have not been filled out, or that any other method of implementation has been used. Connection means that (barring some other fault) a READ or WRITE statement can be executed on the unit, hence on the file. Without a connection, a READ or WRITE statement cannot be executed.
Totally independent of the connection state is the property of existence, this being a file property. The processor "knows" of a set of files that exist at a given time for a given executable program. This set would include tapes ready to read, files in a catalog, a keyboard, a printer, etc. The set may exclude files inaccessible to the executable program because of security, because they are already in use by another executable program, etc. This standard does not specify which files exist, hence wide latitude is available to a processor to implement security, locks, privilege techniques, etc. Existence is a convenient concept to designate all of the files that an executable program can potentially process.
All four combinations of connection and existence may occur:
______________________________________________
| | | |
|_Connect|__Exist|___________Examples_________|
| | | |
| Yes | Yes | A card reader loaded and |
| | | ready to be read |
|________|_______|____________________________|
| | | |
| Yes | No | A printer before the first|
|________|_______|__line_is_written___________|
| | | |
| No | Yes | A file named 'JOE' in |
| | | the catalog |
|________|_______|____________________________|
| | | |
| No | No | A reel of tape destroyed |
|________|_______|__in_the_fire_last_week_____|
Means are provided to create, delete, connect, and disconnect files.
A file may have a name. The form of a file name is not specified. If a system does not have some form of cataloging or tape labeling for at least some of its files, all file names will disappear at the termination of execution. This is a valid implementation. Nowhere does this standard require names to survive for any period of time longer than the execution time span of an executable program. Therefore, this standard does not impose cataloging as a prerequisite. The naming feature is intended to allow use of a cataloging system where one exists.
A file may become connected to a unit in either of two ways: preconnection or execution of an OPEN statement. Preconnection is performed prior to the beginning of execution of an executable program by means external to FORTRAN. For example, it may be done by job control action or by processor established defaults. Execution of an OPEN statement is not required to access preconnected files.
The OPEN statement provides a means to access existing files that are not preconnected. An OPEN statement may be used in either of two ways: with a file name (open by name) and without a file name (open by unit). A unit is given in either case. Open by name connects the specified file to the specified unit. Open by unit connects a processor-determined default file to the specified unit. (The default file may or may not have a name.)
Therefore, there are three ways a file may become connected and hence processed: preconnection, open by name, and open by unit. Once a file is connected, there is no means in standard FORTRAN to determine how it became connected.
In subset FORTRAN, sequential access may be performed only on preconnected files, and direct access only on files that are opened by unit.
An OPEN statement may also be used to create a new file. In fact, any of the foregoing three connection methods may be performed on a file that does not exist. When a unit is preconnected, writing the first record creates the file. With the other two methods, execution of the OPEN statement creates the file.
When a unit becomes connected to a file, either by execution of an OPEN statement or by preconnection, the following connection properties may be established:
The blank significance property of the connection is effective at the beginning of each formatted input statement. During execution of the statement, any BN or BZ edit descriptors encountered may temporarily change the effect of embedded and trailing blanks.
A processor has wide latitude in adapting these concepts and actions to its own cataloging and job control conventions. Some processors may require job control action to specify the set of files that exist or that will be created by an executable program. Some processors may require no job control action prior to execution. This standard enables processors to perform a dynamic open, close, and file creation, but it does not require such capabilities of the processor.
The meaning of "open" in contexts other than FORTRAN may include such things as mounting a tape, console messages, spooling, label checking, security checking, etc. These actions may occur upon job control action external to FORTRAN, upon execution of an OPEN statement, or upon execution of the first read or write of the file. The OPEN statement describes properties of the connection to the file and may or may not cause physical activities to take place. It is a place for an implementation to define properties of a file beyond those required in standard FORTRAN.
Similarly, the actions of dismounting a tape, protection, etc. of a "close" may be implicit at the end of a run. The CLOSE statement may or may not cause such actions to occur. This is another place to extend file properties beyond those of standard FORTRAN. Note, however, that the execution of a CLOSE statement on unit 10 followed by an OPEN statement on the same unit to the same file or to a different file is a permissible sequence of events. The processor may not deny this sequence solely because the implementation chooses to do the physical act of closing the file at the termination of execution of the program.
This standard does not address problems of security, protection, locking, and many other concepts that may be part of the concept of "right of access." Such concepts are considered to be in the province of an operating system. The OPEN and INQUIRE statements can be extended naturally to consider these things.
Possible access methods for a file are: sequential and direct. The processor may implement two different types of files, each with its own access method. It may also implement one type of file with two different access methods.
Direct access to files is of a simple and commonly available type, that is, fixed-length records. The key is a positive integer.
Keyword forms of specifiers are used because there are many specifiers and a positional notation is difficult to remember. The keyword form sets a style for processor extensions. The UNIT= and FMT= keywords are offered for completeness, but their use is optional. Thus, compatibility with ANSI X3.9-1966 is achieved.
Format specifications may be included in READ and WRITE statements, as in:
READ ( UNIT=10, FMT='(I3,A4,F10.2)' ) K,ALPH,X
ANSI X3.9-1966 allowed a standard-conforming program to write an endfile record but did not allow the reading of an endfile record. In this standard, the END= specifier allows end-of-file detection and continuation of execution of the program.
List-directed input/output allows data editing according to the type of the list item instead of by a format specifier. It also allows data to be free-field, that is, separated by commas or blanks.
List-directed input/output is record oriented to or from a formatted sequential file. Each read or write begins with a new record. The form of list-directed data on a sequential output file is not necessarily suitable for list-directed input. However, there are no mandatory errors specified for reading list-directed data previously written. The results may not be guaranteed because of the syntax using apostrophes for character data or the r*c form of a repeated constant. All other applications should work, and attempting to read previously written list-directed output is not prohibited in a standard-conforming program.
If no list items are specified in a list-directed input/output statement, one input record is skipped or one empty output record is written.
An example of a restriction on input/output statements ( 12.12) is that an input statement may not specify that data are to be read from a printer.
If a character constant is used as a format identifier in an input/output statement, care must be taken that the value of the character constant is a valid format specification. In particular, if the format specification contains an apostrophe edit descriptor, two apostrophes must be written to delimit the apostrophe edit descriptor and four apostrophes must be written for each apostrophe that occurs within the apostrophe edit descriptor. For example, the text:
2 ISN'T 3
may be written by various combinations of output statements and format specifications:
Note that two consecutive apostrophes in an H edit descriptor within a character constant are counted as only one Hollerith character.
The T edit descriptor includes the carriage control character in lines that are to be printed. T1 specifies the carriage control character, and T2 specifies the first character that is printed.
The length of a record is not always specified exactly and may be processor dependent.
The number of records read by a formatted input statement can be determined from the following rule: A record is read at the beginning of the format scan (even if the input list is empty), at each slash edit descriptor encountered in the format, and when a format rescan occurs at the end of the format.
The number of records written by a formatted output statement can be determined from the following rule: A record is written when a slash edit descriptor is encountered in the format, when a format rescan occurs at the end of the format, and at completion of execution of the output statement (even if the output list is empty). Thus, the occurrence of n successive slashes between two other edit descriptors causes n - 1 blank lines if the records are printed. The occurrence of n slashes at the beginning or end of a complete format specification causes n blank lines if the records are printed. However, a complete format specification containing n slashes (n >= 0) and no other edit descriptors causes n + 1 blank lines if the records are printed. For example, the statements
will write two records that cause two blank lines if the records are printed.
The following examples illustrate list-directed input.
A
blank character is represented by
b
.
Example 1:
Explanation: The second READ statement reads the second record.
The initial comma in the record designates a null value;
therefore, J is not redefined.
Example 2:
Explanation: The end of a record cannot occur between two apostrophes representing an embedded apostrophe in a character constant; therefore, A is set to the character constant 'bbbbbbbb' . The end of a record acts as a blank, which in this case is a value separator because it occurs between two constants.
The intrinsic function names IFIX, IDINT, FLOAT, and SNGL have been retained to support programs that conform to ANSI X3.9-1966. However, future use of these intrinsic function names is not recommended.
For the specific functions that define the maximum and minimum values with a function type different from the argument type (AMAX0, MAX1, AMIN0, and MIN1), it is recommended that an expression containing the generic name preceded by a type conversion function be used, for example, REAL(MAX(a , a ,...)) 1 2 for AMAX0(a , a ,...) 1 2 , so that these specific function names may be deleted in a future revision of this standard.
This standard provides that a standard-conforming processor may supply intrinsic functions in addition to those defined in Table 5 ( 15.10). Because of this, care must be taken when a program is used on more than one processor because a function name not in Table 5 may be classified as an external function name on one processor and as an intrinsic function name on another processor in the absence of a declaration for that name in an EXTERNAL or INTRINSIC statement.
To guard against this possibility, it is suggested that any external functions referenced in a program should appear in an EXTERNAL statement in every program unit in which a reference to that function appears. If a program unit references a processor-supplied intrinsic function that does not appear in Table 5, the name of the function should appear in an INTRINSIC statement in the program unit.
The distinction between external functions (user defined) and intrinsic functions (processor defined) may be clarified by the following table:
_________________________________________
| |
| Different Processor Definitions |
| ___________(Table_5_extended)___________|
| | | |
| Processor 1| Processor 2| Processor 3|
_______________|_____________|_____________|_____________|
| | | | |
| | | | |
| Different | Intrinsic | Intrinsic | |
| User | Integer | Complex | (none) |
|_Specifications|__FROG_______|__FROG_______|_____________|
| | | | |
|_______________|_____________|_____________|_____________|
| | | | |
| Y=FROG(A) | Intrinsic | Intrinsic | External |
| | Integer | Complex | Real |
|_______________|__FROG_______|__FROG_______|__FROG_______|
| | | | |
| INTRINSIC FROG| Intrinsic | Intrinsic | |
| Y=FROG(A) | Integer | Complex | Undefined |
| | FROG | FROG | |
|_______________|_____________|_____________|_____________|
| | | | |
| INTEGER FROG | Intrinsic | | External |
| Y=FROG(A) | Integer | Undefined | Integer |
|_______________|__FROG_______|_____________|__FROG_______|
| | | | |
| INTRINSIC FROG| Intrinsic | | |
| INTEGER FROG | Integer | Undefined | Undefined |
| Y-FROG(A) | FROG | | |
|_______________|_____________|_____________|_____________|
| | | | |
| EXTERNAL FROG | External | External | External |
| Y=FROG(A) | Real | Real | Real |
|_______________|__FROG_______|__FROG_______|__FROG_______|
| | | | |
| EXTERNAL FROG | External | External | External |
| INTEGER FROG | Integer | Integer | Integer |
| Y=FROG(A) | FROG | FROG | FROG |
|_______________|_____________|_____________|_____________|
If a generic name is the same as the specific name of an intrinsic function for a specified type of argument, a reference to the function with an argument of that type may be considered to be either a specific or generic function reference.
The use of the concatenation operator with operands of nonconstant length has been restricted to the assignment statement so that a processor need not implement dynamic storage allocation.
When a character array is an actual argument, the array is considered to be one string of characters and there need not be correspondence between the actual array elements and the dummy array elements. Only subset FORTRAN requires such correspondence.
The intrinsic functions ICHAR and CHAR provide a means of converting between a character and an integer, based on the position of the character in the processor collating sequence. The first character in the collating sequence corresponds to position 0 and the last to position n - 1 , where n is the number of characters in the collating sequence.
Many processors provide a collating sequence that is the same as the ordering of the internal representation of the character (where the internal representation may be regarded as either a representation of a character or of some integer). For example, for a seven-bit character, the internal representation of the first character is '0000000' binary (0 decimal) and the last character is '1111111' binary (127 decimal). For such a processor, ICHAR returns the value of an internal character representation, considered as an integer. CHAR takes an appropriate small integer and returns the character having the same internal representation.
The definition of character entities occurs on a character-by-character basis. The use of substrings or partially associated entities permits individual characters or groups of characters within an entity to become defined or undefined.
'
The character data type was added to provide a character data processing capability that is superior to the Hollerith data capability that existed in ANSI X3.9-1966.
The Hollerith data type has been deleted. For processors that extend the standard by allowing Hollerith data, the following rules for programs are recommended:
A Hollerith datum is a string of characters. The string may consist of any characters capable of representation in the processor. The blank character is significant in a Hollerith datum. Hollerith data may have an internal representation that is different from that of other data types.
An entity of type integer, real, or logical may be defined with a Hollerith value by means of a DATA statement (C4) or READ statement (C6). When an entity is defined with a Hollerith value, its totally associated entities are also defined with that Hollerith value. When an entity of type integer, real, or logical is defined with a Hollerith value, the entity and its associates become undefined for use as an integer, real, or logical datum.
In a Hollerith constant, blanks are significant only in the n characters following the letter H.
A Hollerith constant may appear in the list clist , and the corresponding entity in the list nlist may be of type integer, real, or logical.
For an entity of type integer, real, or logical, the number of characters n in the corresponding Hollerith constant must be less than or equal to g , where g is the maximum number of characters that can be stored in a single numeric storage unit at one time. If n is less than g , the entity is initially defined with the n Hollerith characters extended on the right with g - n blank characters.
Note that each Hollerith constant initially defines exactly one variable or array element. Also note that g is processor dependent.
The leftmost characters of the specified entity must contain Hollerith data that constitute a format specification when the statement is executed.
The format specification must be of the form described in 13.2. It must begin with a left parenthesis and must end with a right parenthesis. Data may follow the right parenthesis that ends the format specification and have no effect. Blank characters may precede the format specification.
A Hollerith format specification must not contain an apostrophe edit descriptor or an H edit descriptor.
Editing is as described for Aw editing of character data except that len is the maximum number of characters that can be stored in a single numeric storage unit.
'
This Appendix provides an overview of the two levels of FORTRAN specified in this standard, including the general criteria used for including or excluding a feature at a given level, and a section-by-section summary of the principal differences between the full language and the subset.
The ISO R1539 document describes three levels: basic, intermediate, and full. The ISO R1539 basic level corresponds closely with ANSI X3.10-1966; the ISO R1539 full level corresponds closely with ANSI X3.9-1966; and the ISO R1539 intermediate level is in between.
It was thought that the ISO R1539 basic level and the ANSI X3.10-1966 had not been sufficiently used, even on small computer systems, to warrant a subset corresponding to that level.
The ISO R1539 intermediate level has been sufficiently used to warrant a subset of similar capability.
However, it was also thought that some of the capabilities in the full language described here, but not part of any current standard or recommendation, are so important for the general use of the language that they should be present in the subset, at least to some degree.
Furthermore, it was thought that the specification of ANSI X3.10-1966 in such a manner that it is not a subset of ANSI X3.9-1966 was inconsistent with the primary goal of promoting program interchange. Consequently, careful attention has been given to ensuring that a program that conforms to the subset of this standard will also conform to the full language.
An exception to the above practice is the subsetting of the character data type. The description of character data type and its usage is so distributed throughout the standard that a more meaningful summary is produced by collecting the relevant items into a single presentation.
Note that DATA statements must follow all specification statements and precede all statement function statements and executable statements.
Iw.m Tc S
Dw.d TLc SP
Gw.d TRc SS
Gw.dEe
Other exclusions are presented in D3.19, most notably an asterisk character length specifier, character functions, the intrinsic functions LEN, CHAR, and INDEX, and partial association.
As an example, a standard-conforming subset processor may provide a double precision data type provided that the requirements for double precision are fulfilled.
A subset-conforming program may not use such names as intrinsic functions because these names are not defined as intrinsic functions in the subset language. Moreover, a subset-conforming program may not use such names as external function names unless such names are identified as external function names by appearing in an EXTERNAL statement. If such names are not explicitly declared as external, the names would be classified as external by a subset processor and as intrinsic by a full language processor. Note that the burden of avoiding this situation rests on the program. A subset-conforming processor is not required to recognize that a full language intrinsic name is being used without being declared as external. In effect, the full set of names described in Table 5 may be considered as reserved intrinsic function names in the subset even though only a subset of those names is available for use.
'
Form Descriptive_Heading
ASSIGN s TO i Statement Label
Assignment Statement
BACKSPACE u File Positioning
BACKSPACE (alist) Statements
BLOCK DATA [sub] BLOCK DATA Statement
CALL sub [([a [,a]...])] Subroutine Reference:
CALL Statement
CHARACTER [*len[,]] nam [,nam]... Character Type-
Statement
CLOSE (cllist) CLOSE Statement
COMMON [/[cb]/]nlist[[,]/[cb]/nlist]... COMMON Statement
COMPLEX v [,v]... Complex Type-
Statement
CONTINUE CONTINUE Statement
DATA nlist/clist/ [[,]nlist/clist/]... DATA Statement
DIMENSION a(d) [,a(d)]... DIMENSION Statement
DO s [,] i=e ,e [,e ] DO Statement
1 2 3
DOUBLE PRECISION v [,v]... Double Precision
Type-Statement
ELSE ELSE Statement
ELSE IF (e) THEN ELSE IF Statement
END END Statement
END IF END IF Statement
ENDFILE u File Positioning
ENDFILE (alist) Statements
ENTRY en [([d [,d]...])] ENTRY Statement
EQUIVALENCE (nlist) [,(nlist)]... EQUIVALENCE Statement
EXTERNAL proc [,proc]... EXTERNAL Statement
Form Descriptive_Heading
FORMAT fs FORMAT Statement
fun ([d [,d]...]) = e Statement Function
Statement
[typ] FUNCTION fun ([d [,d]...]) FUNCTION Statement
GO TO i [[,](s [,s]...)] Assigned GO TO
Statement
GO TO s Unconditional GO TO
Statement
GO TO (s [,s]...)[,] i Computed GO TO
Statement
IF (e) st Logical IF Statement
IF (e) s , s , s Arithmetic IF
1 2 3 Statement
IF (e) THEN Block IF Statement
IMPLICIT typ (a [,s]...) IMPLICIT Statement
[,typ (a [,a]...)]...
INQUIRE (iflist) INQUIRE by File
Statement
INQUIRE (iulist) INQUIRE by Unit
Statement
INTEGER v [,v]... Integer Type-
Statement
INTRINSIC fun [,fun]... INTRINSIC Statement
LOGICAL v [,v]... Logical Type-
Statement
OPEN (olist) OPEN Statement
PARAMETER (p=e [,p=e]...) PARAMETER Statement
PAUSE [n] PAUSE Statement
PRINT f [,iolist] Data Transfer Output
Statement
PROGRAM pgm PROGRAM Statement
Form Descriptive_Heading
READ (cilist) [iolist] Data Transfer Input
Statement
READ f [,iolist] Data Transfer Input
Statement
REAL v [,v]... Real Type-Statement
RETURN [e] RETURN Statement
REWIND u File Positioning
REWIND (alist) Statements
SAVE [a [,a]...] SAVE Statement
STOP [n] STOP Statement
SUBROUTINE sub [([d [,d]...])] Subroutine Subprogram
and SUBROUTINE
Statement
v = e Arithmetic Assignment
Statement
v = e Logical Assignment
Statement
v = e Character Assignment
Statement
WRITE (cilist) [iolist] Data Transfer Output
Statement
'