From david@imagine1.com Mon Jan 13 01:21:35 1997 Received: from kitsune.swcp.com (kitsune.swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id BAA25893 for ; Mon, 13 Jan 1997 01:21:30 +0100 Received: from ppp135.swcp.com (ppp135.swcp.com [204.134.0.185]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id RAA02721 for ; Sun, 12 Jan 1997 17:21:13 -0700 Date: Sun, 12 Jan 1997 17:21:13 -0700 Message-Id: <199701130021.RAA02721@kitsune.swcp.com> X-Sender: evt@swcp.com (Unverified) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_853110794==_" To: sc22wg5@dkuug.dk From: david@imagine1.com (David Epstein) Subject: Part III, Coco X-Mailer: X-Attachments: C:\DE\WG5\COCO\WG5COCOA.TXT; --=====================_853110794==_ Content-Type: text/plain; charset="us-ascii" --=====================_853110794==_ Content-Type: text/plain; charset="us-ascii" To: SC22WG5 and X3J3 From: David Epstein Subject: Part III, Conditional Compilation Dear SC22WG5 and X3J3, Below is the proposed Part III of the standard regarding conditional compilation (coco). I introduced a conditional compilation facility (CCF) to X3J3 in 1993. At the last seven X3J3 meetings, coco has been discussed at increased depth and intensity along the road of standardization. At the San Diego SC22WG5 meeting, a vote between a Fortran-like approach and a cpp-like approach was 13-1-10 in favor of the Fortran-like approach. At the Dresden SC22WG5 meeting, a vote between a Fortran-like definition and fpp (a cpp-like definition) was 13-6 in favor of the Fortran-like definition. I am pleased to provide the below Fortran-like conditional compilation language definition, an updated version of the definition presented in Dresden. This document was reviewed by Dick Hendrickson, Jeanne Martin and John Reid. My thanks to these reviewers. My thanks also to the coco development body and the primary development body for their designing and reviewing efforts during the last two years. Miles or Mallory, please assign this paper a number for Las Vegas. A PostScript version of this paper will be available shortly. Looking forward to discussing this paper in Las Vegas, David Epstein Imagine1, Inc. david@imagine1.com ======================================================================= CONDITIONAL COMPILATION IN FORTRAN ISO/IEC 1539-3 : 1997 {Auxiliary to ISO/IEC 1539 : 1997 "Programming Language Fortran"} CONTENTS 1. Introduction 2. Rationale 3. General 1. Scope 2. Normative References 4. The Conditional Compilation Language Definition Annex CCA : Examples 1. INTRODUCTION ---------------------------------------------------- This part of ISO/IEC 1539 has been prepared by ISO/IEC JTC1/SC22/WG5, the technical working group for the Fortran language. This part of ISO/IEC 1539 is an auxiliary standard to ISO/IEC 1539 : 1997, which defines the latest revision of the Fortran language, and is the first part of the multipart Fortran family of standards; this part of ISO/IEC 1539 is the third part. The revised language defined by the above standard is informally known as Fortran 95. This part of ISO/IEC 1539 defines a conditional compilation language facility. 2. RATIONALE ------------------------------------------------------- Programmers often maintain multiple copies of code to vary the features or allow for different operating systems. Keeping several copies of the source code is error prone. A conditional compilation language facility permits the programmer to rely on the processor to select blocks of code based on specified conditions. The additional lines inserted to control this process and all the lines that are not selected are marked to be skipped by the processor during the compilation phase. These lines have no effect on the interpretation of the source during the compilation phase and conceptually are replaced by comment lines. 3. GENERAL --------------------------------------------------------- 1. Scope This part of ISO/IEC 1539 defines facilities for use in Fortran for conditional compilation. This part of ISO/IEC 1539 provides an auxiliary standard for the version of the Fortran language informally known as Fortran 95. The international Standard defining this revision of the Fortran language is ISO/IEC 1539-1 : 1997 "Programming Language Fortran" 2. Normative References The following standard contains provisions which, through reference in this text, constitute provisions of this part of ISO/IEC 1539. At the time of publication, the edition indicated was valid. All standards are subject to revision, and parties to agreements based on this part of ISO/IEC 1539 are encouraged to investigate the possibility of applying the most recent editions of the standard indicated below. Members of IEC and ISO maintain registers of currently valid International Standards. ISO/IEC 1539-1 : 1997, Information technology--Programming Languages--Fortran. 4. THE CONDITIONAL COMPILATION LANGUAGE DEFINITION ----------------- Section CC1 Overview CC1.1 Conditional compilation and preprocessing Conditional compilation (coco) is achieved during a preprocessing phase that is controlled by directives in the source text. These directives and any source lines skipped by the conditional compilation have no effect on the interpretation of the source during the compilation phase. The compilation phase, which is described in part 1 of this standard, is referred to as the post-coco processing phase in this part of ISO/IEC 1539. The execution of coco directives occurs during a phase called the preprocessing phase because conceptually it occurs before the post-coco processing phase described in part 1 of this standard. Coco execution is a sequence, in time, of actions specified by the coco directives. The actions are performed in the order that the directives appear. The result is conceptually a sequence of lines that is identical to the original sequence except that all coco directive lines are replaced by comment lines or deleted and all lines within a coco FALSE block (CC6.2.2.2) are replaced by comment lines or deleted. The lines that are conceptually replaced by comment lines or deleted are referred to as lines that are marked to be skipped during post-coco processing. Note CC1.1 Coco execution may be performed by a processor that is separate from the Fortran processor and passes altered source lines to the Fortran processor. Alternatively, it may be integrated into the Fortran processor. ENDNote CC1.1 CC1.2 Section numbers and syntax rules In this part of ISO/IEC 1539, sections are numbered CCs, where s is a one or two-digit section number. The notation used in this part of ISO/IEC 1539 is described in Part 1, section 1.6. However, item (4) in Part 1, section 1.6.2 is replace with: (4) Each syntax rule is given a unique identifying number of the form CCRsnn, where s is a one or two-digit section number and nn is a two-digit sequence number within that section. The syntax rules are distributed as appropriate throughout the text, and are referenced by number as needed. Some rules in Section CC2 and CC3 are more fully described in later sections; in such cases, the section number s is the number of the later section where the rule is repeated. Section CC2 High level syntax This section introduces the terms associated with the conditional compilation program. CCR201 coco-program is pp-input-item [ pp-input-item ] ... CCR202 pp-input-item is coco-construct or noncoco-line The term refers to any line without the characters "??" in character positions 1 and 2. CCR203 coco-construct is coco-type-declaration-directive or coco-executable-construct CCR204 coco-executable-construct is coco-action-directive or coco-if-construct CCR205 coco-action-directive is coco-assignment-directive or coco-error-directive or coco-stop-directive Section CC3 Constants, source form and including text CC3.1 Coco constants CCR301 coco-constant is coco-literal-constant or coco-named-constant CCR302 coco-literal-constant is coco-int-literal-constant or coco-logical-literal-constant CCR303 coco-int-literal-constant is digit-string CCR304 coco-logical-literal-constant is .TRUE. or .FALSE. CCR305 coco-char-literal-constant is ' [ rep-char ] ... ' or " [ rep-char ] ... " CCR306 coco-named-constant is name Constraint: coco-named-constant shall have the PARAMETER attribute. [digit-string is specified in part 1, R402 of this standard.] [rep-char is specified in part 1, section 4.3.2.1 of this standard.] [A name is specified in part 1, section 3.2.1 of this standard.] CC3.2 Coco source form A coco program is a sequence of one or more lines, organized as coco directives, coco comment lines (CC3.2.1) and noncoco lines. A coco directive is a sequence of one or more coco lines. A coco line is a line with the characters "??" in character positions 1 and 2. These characters are not part of the coco directive. A noncoco line is a line that does not begin in this way. A coco character context means characters within a coco character literal constant (CCR305). A coco comment may contain any character that may occur in any coco character context. In coco source, each source line may contain from zero to 132 characters. In coco source, blank characters shall not appear within coco lexical tokens other than in a coco character context. Blanks may be inserted freely between coco tokens to improve readability. A sequence of blank characters outside of a coco character context is equivalent to a single blank character. [Lexical token is specified in part 1, section 3.2 of this standard.] A blank shall be used to separate coco names, or coco constants from adjacent keywords, coco names, or coco constants. One or more blanks shall be used to separate adjacent keywords except in the following cases, where blanks are optional: Adjacent keywords where separating blanks are optional ELSE IF END IF CC3.2.1 Coco commentary Within a coco directive, the character "!" in any character position initiates a coco comment except when it appears within a coco character context. The coco comment extends to the end of the source line. If the first nonblank character on a coco line after character positions 1 and 2 is an "!", the line is a coco comment line. Coco lines containing only blanks after character positions 1 and 2 or containing no characters after character positions 1 and 2 are also coco comment lines. Note CC3.1 Examples of coco comment lines are: ?? ! SET "SYSTEM" TO "SYSTEM_A" ?? ENDNote CC3.1 CC3.2.2 Coco directive continuation The character "&" is used to indicate that the current coco directive is continued on the next line. The next line shall be a coco line. Coco comment lines shall not be continued; an "&" in a coco comment has no effect during coco execution. When used for continuation, the "&" is not part of the coco directive. After character positions 1 and 2, no coco line shall contain a single "&" as the only nonblank character or as the only nonblank character before an "!" that initiates a coco comment. CC3.2.2.1 Coco-noncharacter context continuation In a coco directive, if an "&" not in a coco comment is the last nonblank character on a line or the last nonblank character before an "!" that initiates a coco comment, the coco directive is continued on the next line. If the first nonblank character after character positions 1 and 2 on the next coco-noncomment line is an "&", the coco directive continues at the next character following the "&"; otherwise, it continues with the first character position after character positions 1 and 2 of the next coco-noncomment line. If a coco lexical token is split across the end of a line, the first nonblank character after character positions 1 and 2 on the first following coco-noncomment line shall be an "&" immediately followed by the successive characters of the split token. Note CC3.2 An example of coco-noncharacter context continuation is: ?? LOGICAL :: TOO_GOOD& ??&_TO_BE_& ??&TRUE = & ?? ! These six lines contain 1 coco directive ?? ! and two coco comment lines. ?? .FALSE. ENDNote CC3.2 CC3.2.2.2 Coco character context continuation If a coco character context is to be continued, the "&" shall be the last nonblank character on the line and shall not be followed by coco commentary. An "&" shall be the first nonblank character after character positions 1 and 2 on the next line and the coco directive continues with the next character following the "&". Note CC3.3 An example of coco character context continuation is: ?? ERROR "DE& ?? &F& ?? &INE VALID 'SYSTEM' VALUE" ! 3 lines, 1 coco directive ENDNote CC3.3 CC3.2.3 Coco directives If a coco directive has one or more continuation lines, every line from the start of the coco directive until the end of the coco directive shall be a coco line. A coco directive shall not have more than 39 continuation lines. Note CC3.4 Examples of coco directives are: ?? INTEGER, PARAMETER :: SYSTEM_A = 1 ?? ERROR "SYSTEM_A = ", SYSTEM_A ?? IF (.FALSE.) THEN ?? ENDIF ENDNote CC3.4 CC3.3 Including source text Additional text may be incorporated into the source text of a coco program during coco execution. This is accomplished with the INCLUDE line, which has the form INCLUDE char-literal-constant [The INCLUDE line is specified in part 1, section 3.4 of this standard.] Included source text cannot directly or indirectly include itself. An INCLUDE line in a coco FALSE block (CC6.2.2) is not expanded. Each coco directive that is a coco-else-if-directive, coco-else-directive, or coco-endif-directive shall appear in the same source text as the matching coco-if-directive; that is, the directives that create a coco IF construct (CC6.2) shall not be split across included source text. Note CC3.5 An example of erroneous included source text is: ?? ELSEIF (version == V8) THEN PRINT *, "The matching coco IF is missing" ?? ELSE PRINT *, "Wow, the matching coco ENDIF is also missing" ENDNote CC3.5 Section CC4 Coco type declaration directives Every data object has a type and may have the PARAMETER attribute. The type of a named data object, and possibly the PARAMETER attribute, is specified in a type declaration directive. CCR401 coco-type-declaration-directive is > < coco-type-spec [ , PARAMETER ] :: coco-entity-decl-list CCR402 coco-type-spec is INTEGER or LOGICAL CCR403 coco-entity-decl is > < coco-object-name [ coco-initialization ] Constraint: A coco-object-name shall not be the same as any other coco-object-name in its coco-type-declaration-directive or any other executed coco-type-declaration-directive. Constraint: coco-object-name shall appear in an executed coco-type-declaration-directive before appearing elsewhere in a coco program. CCR404 coco-initialization is = coco-initialization-expr Constraint: The types of the coco-initialization-expr and the coco-type-spec shall either both be integer or both be logical. Constraint: In a coco-type-declaration-directive, if the PARAMETER attribute is specified, a coco-initialization shall appear for every coco-object-name. Note CC4.1 Examples of coco type declaration directives are: ?? INTEGER, PARAMETER :: F77 = 1, F90 = 2, F95 = 3, F2000 = 4 ?? INTEGER :: FORTRAN_LEVEL = F95 ?? LOGICAL :: DEBUG_PROCEDURE_ENTRY_EXIT ENDNote CC4.1 Note CC4.2 Coco type declaration directives are not required to appear before coco executable constructs. ENDNote CC4.2 Section CC5 Coco variables, expressions and assignment directive CC5.1 Coco variables CCR501 coco-variable is coco-variable-name Constraint: coco-variable-name shall not have the PARAMETER attribute. CC5.2 Coco expressions CC5.2.1 Coco primary CCR502 coco-primary is coco-constant or coco-variable or ( coco-expr ) Constraint: A coco-variable shall be defined (CC8.2) before appearing as a coco-primary. CC5.2.2 Level-1 expressions CCR503 coco-add-operand is > < [ coco-add-operand mult-op ] coco-primary CCR504 coco-level-1-expr is > < [ [ coco-level-1-expr ] add-op ] coco-add-operand [mult-op and add-op are specified in part 1, section 7.1.1.3 of this standard.] CC5.2.3 Level-2 expressions CCR505 coco-level-2-expr is > < [ coco-level-1-expr rel-op ] coco-level-1-expr [rel-op is specified in part 1, section 7.1.1.5 of this standard.] CC5.2.4 Level-3 expressions CCR506 coco-and-operand is > < [ not-op ] coco-level-2-expr CCR507 coco-or-operand is > < [ coco-or-operand and-op ] coco-and-operand CCR508 coco-equiv-operand is > < [ coco-equiv-operand or-op ] coco-or-operand CCR509 coco-level-3-expr is > < [ coco-level-3-expr equiv-op ] coco-equiv-operand [not-op, and-op, or-op and equiv-op are specified in part 1, section 7.1.1.6 of this standard.] CC5.2.5 General form of a coco expression CCR510 coco-expr is coco-level-3-expr CC5.3 Data type of a coco expression The data type of a coco expression is either Integer or Logical. [The data type of a coco expression is specified in part 1, table 7.1 of this standard.] Note CC5.2 The following table of operator precedence differs from table 7.8 in part 1 of this standard only by the removal of defined operators, exponentiation and concatenation: Table CC7.1 Categories of operations and relative precedences Category of Operation Operators Precedence Term Numeric * or / Highest mult-op Numeric unary + or - . add-op Numeric binary + or - . add-op Relational .EQ., .NE., .LT., .LE., .GT., .GE. . rel-op ==,/=, <, <=, >, >= Logical .NOT. . not-op Logical .AND. . and-op Logical .OR. . or-op Logical .EQV. or .NEQV. Lowest equiv-op ENDNote CC5.2 CCR511 coco-logical-expr is coco-expr Constraint: coco-logical-expr shall be type logical. CC5.4 Coco initialization expression CCR512 coco-initialization-expr is coco-expr Constraint: A coco-initialization-expr shall not have a coco-variable as a coco-primary. CC5.5 Coco assignment directive A coco variable may be defined or redefined by execution of a coco assignment directive. CCR513 coco-assignment-directive is coco-variable = coco-expr In a coco assignment directive, the types of coco-variable and coco-expr shall either both be integer or both be logical. Note CC5.3 Examples of coco assignment directives are: ?? DEBUG_LEVEL = DEBUG_LEVEL + 1 ?? IS_COMPANY_X_MACHINE = (SYSTEM == SYS_E) .OR. (SYSTEM == SYS_F) ?? PROJECT_LEVEL = FOO_VERSION + LATEST_RELEASE ENDNote CC5.3 Section CC6 Coco execution control and conditional compilation The execution sequence and conditional compilation are controlled by coco if constructs. Note CC6.1 A coco program is not required to contain any coco directives. ENDNote CC6.1 CC6.1 Coco blocks A coco block is a sequence of coco directives, coco comment lines, INCLUDE lines and noncoco lines that are treated as a unit. CCR601 coco-block is [ pp-input-item ] ... Coco executable constructs may be used to control which coco blocks of a coco program are skipped during post-coco processing. CC6.2 Coco IF construct The coco IF construct marks to be skipped during post-coco processing all but at most one of its constituent coco blocks. If there is a coco block that is not marked to be skipped during post-coco processing, it is called the coco TRUE block. The remaining coco blocks are called coco FALSE blocks. CC6.2.1 Form of the coco IF construct CCR602 coco-if-construct is coco-if-then-directive coco-block [ coco-else-if-directive coco-block ] ... [ coco-else-directive coco-block ] coco-end-if-directive CCR603 coco-if-then-directive is > < IF ( coco-logical-expr ) THEN CCR604 coco-else-if-directive is > < ELSE IF ( coco-logical-expr ) THEN CCR605 coco-else-directive is ELSE CCR606 coco-end-if-directive is END IF Note CC6.2 An example of two coco if constructs, one nested within the other, is: ?? IF (IS_COMPANY_X_MACHINE) THEN ?? IF (FORTRAN_LEVEL == F95) THEN PURE FUNCTION GET_RABBIT_WEIGHT(A_RABBIT) RESULT(WEIGHT) TYPE (RABBIT), INTENT(IN) :: A_RABBIT ?? ELSEIF (FORTRAN_LEVEL == F90) THEN FUNCTION GET_RABBIT_WEIGHT(A_RABBIT) RESULT(WEIGHT) TYPE (RABBIT) :: A_RABBIT ?? ELSE ?? ERROR "We do not have a FORTRAN 77 product from company X" ?? ENDIF ?? ELSE FUNCTION GET_RABBIT_WEIGHT() RESULT(WEIGHT) ?? ENDIF ENDNote CC6.2 CC6.2.2 Execution of an IF construct At most one of the coco blocks in the coco IF construct is selected as a coco TRUE block. If there is a coco ELSE directive in the construct, exactly one of the coco blocks in the construct will be selected as a coco TRUE block. The coco logical expressions are evaluated in the order of their appearance in the construct until a true value is found or a coco ELSE directive or coco END IF directive is encountered. If a true value or a coco ELSE directive is found, the coco block immediately following is selected as a coco TRUE block and this completes the execution of the construct. The coco logical expressions in any remaining coco ELSE IF directives of the coco IF construct are not evaluated. If none of the evaluated expressions are true and there is no coco ELSE directive, the execution of the construct is completed without the selection of any coco block within the construct as a coco TRUE block. All other blocks of the construct are selected as coco FALSE blocks. Any coco IF constructs nested within a coco TRUE block are treated similarly. No coco processing occurs for coco IF constructs nested within a coco FALSE block. No coco processing occurs for coco action directives, coco type declaration directives or INCLUDE lines within a coco FALSE block. Execution of a coco END IF directive has no effect. Note CC6.3 An example of declaring a coco variable and including source inside a coco IF construct is: ?? IF (MACHINE==BIG) THEN ?? INTEGER :: CHIPS = 3 INCLUDE "STUFF.BIG" ?? ELSE ?? INTEGER :: CHIPS = 1 INCLUDE "STUFF.ONE" ?? ENDIF ENDNote CC6.3 CC6.2.2.1 Execution of a coco TRUE block Source lines contained in a coco TRUE block are processed by the coco processor. CC6.2.2.2 Execution of a coco FALSE block Source lines contained in a coco FALSE block are marked to be skipped during post-coco processing. Note CC6.4 If a processor offers an output file as a result of coco execution, some possible options on the handling of coco directive lines and lines in a coco FALSE block are: (1) delete them, (2) replace them with blank lines, (3) replace them with a "!" in character position 1, followed by the original source line shifted one position to the right, (4) replace them with a "!" in character position 1, followed by the the characters starting from character position 2 of the original source line, or (5) replace them with a "!?>" in character positions 1 to 3, followed by the original source line shifted three positions to the right. All other lines could be copied without modification into the output file. ENDNote CC6.4 Section CC7 Coco error directive and coco stop directive CCR701 coco-error-directive is > < ERROR [ coco-output-item-list ] CCR702 coco-output-item is coco-expr or coco-char-literal-constant Execution of a coco ERROR directive specifies that a programmer detected error has occurred during coco execution. At the time of execution of a coco ERROR directive, the output-item-list, if any, is available in a processor-dependent manner. Execution of a coco ERROR directive does not halt coco execution. Note CC7.1 Examples of the coco error directive are: ?? ERROR "system shall be set to 'sys1' or 'sys2'" ?? ERROR "system = ", SYSTEM ?? ERROR ENDNote CC7.1 CCR703 coco-stop-directive is STOP Execution of a coco STOP directive specifies that a severe programmer detected error has occurred during coco execution. Execution of a coco STOP directive halts coco execution. At the time of execution of a coco STOP directive, the fact that coco execution was halted by the execution of a coco STOP directive is available in a processor-dependent manner. Note CC7.2 When an error has occurred during coco execution, whether or not post-coco processing follows is processor-dependent. ENDNote CC7.2 Note CC7.3 An example of using the coco ERROR directive and the coco STOP directive for error reporting is: ?? IF (MACHINE==BIG) THEN ?? INTEGER :: CHIPS = 3 INCLUDE "STUFF.BIG" ?? ELSEIF (MACHINE==SMALL) THEN ?? INTEGER :: CHIPS = 1 INCLUDE "STUFF.ONE" ?? ELSE ?? ERROR "SET MACHINE TO EITHER BIG OR SMALL" ?? ERROR "MACHINE = ", MACHINE ?? ERROR "PREPROCESSING ERROR. HALTING! " ?? STOP ! FATAL ERROR. HALT COCO EXECUTION ?? ENDIF ENDNote CC7.3 Section CC8 Scope and definition of coco variables CC8.1 Scope of coco variables Coco variables have the scope of the coco program in which they are declared. CC8.2 Events that cause coco variables to become defined Coco variables become defined as follows: (1) Execution of a coco assignment directive causes the coco variable that precedes the equals to become defined. (2) Execution of a coco initialization in a coco type declaration directive causes the coco variable that precedes the equals to become defined. (3) Execution of the coco-set-option (Section CC10) causes the coco variable to become defined. Section CC9 Coco program conformance A coco program is a standard-conforming coco program if it uses only those forms and relationships herein and if the program has an interpretation according to this standard. A coco processor conforms to this standard if: (1) It executes any standard-conforming coco program in a manner that fulfills the interpretations herein, subject to any limits that the processor may impose on the size and complexity of the coco program. (2) It contains the capability to detect and report the use within a submitted coco program of an additional form or relationship that is not permitted by the numbered syntax rules or their associated constraints. (3) It contains the capability to detect and report the use within a submitted coco program of source form not permitted by Section CC3. (4) It contains the capability to detect and report the use within submitted coco SET options of values and names not permitted by Section CC10. (5) It contains the capability to detect and report the reason for rejecting a submitted program. Section CC10 The coco SET option There is one coco option--the coco-set-option. A processor shall supply at least one method of recognizing the coco-set-option separate from the coco program. A processor may allow many coco-set-options. Note CC10.1 The invocation line may be the chosen method of communicating the coco-set-option to the processor. Another method of communicating the coco-set-option to the processor could be a coco input file. ENDNote CC10.1 The coco-set-option is a method of (1) documenting the value of a coco PARAMETER; (2) assigning an initial value to a coco variable (CCR501); (3) overriding the initial value assigned to a coco variable in a coco initialization expression (CCR512) without editing the coco program. The coco-set-option consists of one or more pairs of coco-object-names and coco-literal-constants. The requirements on the coco-object-names and coco-literal-constants are as follows: (1) A coco-object-name specified in a coco-set-option shall be declared in a coco type declaration directive in the coco program. The coco-literal-constant specified in a coco-set-option shall match the type specified in the coco type declaration directive for the coco-object-name. (2) The type of a coco-object-name specified in a coco-set-option shall match the type of its coco-literal-constant. (3) If a coco-object-name specified in a coco-set-option has the PARAMETER attribute specified in its coco type declaration directive, the value of its coco-literal-constant shall match the value supplied in its coco type declaration directive. (4) If a coco-object-name specified in a coco-set-option appears in the coco program as the coco variable in a coco assignment directive, it shall appear at least once in a previous coco executable construct or be initialized in its coco type declaration directive. An example that shows the enforcement of this requirement is found in Note CC10.4 Note CC10.2 A processor may allow other representations for constants and expressions in a coco-set-option. For example, the characters 'T' or 'F' could be used to represent .TRUE. or .FALSE. respectively. In this case it is as if .TRUE. or .FALSE. were specified as the coco-literal-constant. ENDNote CC10.2 If a coco-object-name specified in a coco-set-option has the PARAMETER attribute specified in its coco type declaration directive, this coco-object-name and coco-literal-constant pair has no effect. Otherwise, the coco-set-option for this coco-object-name and coco-literal-constant pair acts as if a coco assignment directive (CCR513)--which consists of the specified coco-object-name as the coco variable and the coco-literal-constant as the coco expression (CCR510)--were placed immediately following the coco type declaration directive that declared the coco-object-name. Note CC10.3 A coco-object-name that has the PARAMETER attribute is allowed in a coco-set-option for documentation purposes. For example, the following coco-set-option: COCO-SET-OPTION->DOS=1,MAC=2,UNIX=3,SYSTEM=1 will override the initial value given to the coco-variable SYSTEM in the following source text: ?? INTEGER, PARAMETER :: DOS = 1, MAC = 2, UNIX = 3, OTHER = 4 ?? INTEGER :: SYSTEM = UNIX Note that the syntax shown above for the coco-set-option is simply one example syntax, using an arrow ("->"), and equals ("=") and a comma (","), that may be used for the coco-set-option. ENDNote CC10.3 Note CC10.4 The value assigned to a coco variable with the coco-set-option does not override the value assigned to a coco variable with the coco assignment directive. The above fourth requirement may save the inexperienced programmer from expecting that the coco-set-option: COCO-SET-OPTION(DOS=1:MAC=2:UNIX=3:SYSTEM=1) will override the initial value given to the coco-variable SYSTEM in the following source text: ?? INTEGER, PARAMETER :: DOS = 1, MAC = 2, UNIX = 3, OTHER = 4 ?? INTEGER :: SYSTEM ?? SYSTEM = UNIX A coco processor shall detect and report that coco-variable SYSTEM is initialized in the coco-set-option, but the specified initial value is not used. Note that the syntax shown above for the coco-set-option is simply one example syntax, using parentheses ("(",")"), and equals ("=") and a colon (":"), that may be used for the coco-set-option. ENDNote CC10.4 Annex CCA : EXAMPLES ------------------------------------------------- This annex includes two examples illustrating the use of facilities conformant with this part of ISO/IEC 1539. The first example uses conditional compilation to facilitate the editing of a large block comment. The second example uses conditional compilation to provide debugging information upon entering and exiting procedures. The example intentionally has a programming bug in it. Note, the conditional compilation directives in this example could be automatically generated. Each example contains a conditional compilation program and a possible output file from conditional compilation execution. The first example shows an output file from conditional compilation execution that handles the lines treated as comments by shifting them three positions to the right and placing the characters "!?>" in character positions one to three. --- initial text ------------------------------------------ ! EXAMPLE 1 shows a possible shift file for output ?? IF (.FALSE.) THEN One convenient use of conditional compilation is the ability to write large comments that span across many lines without requiring each line to start with a "!". Since conditional compilation specifies blocks of lines to be skipped over by the processor, this whole paragraph can be written and modified without the overhead of making sure that each line is a Fortran comment. One can imagine this use of conditional compilation for header comments preceding Fortran programs, modules and procedures. ?? ENDIF --- possible text output from conditional compilation execution --- ! EXAMPLE 1 shows a possible shift file for output !?>?? IF (.FALSE.) THEN !?> !?>One convenient use of conditional compilation is the !?>ability to write large comments that span across many !?>lines without requiring each line to start with a "!". !?>Since conditional compilation specifies blocks of lines !?>to be skipped over by the processor, this whole paragraph !?>can be written and modified without the overhead of !?>making sure that each line is a Fortran comment. !?> !?>One can imagine this use of conditional compilation for !?>header comments preceding Fortran programs, modules and !?>procedures. !?> !?>?? ENDIF --- initial text ------------------------------------------ ! EXAMPLE 2 shows a possible short file for output ?? LOGICAL :: DEBUG_PROC_NAME = .FALSE. ?? LOGICAL :: DEBUG_PROC_ARGS = .FALSE. ?? ! Make sure to debug the procedure name if debugging the arguments ?? DEBUG_PROC_NAME = DEBUG_PROC_NAME .OR. DEBUG_PROC_ARGS SUBROUTINE INTSWAP (LEFT, RIGHT) INTEGER, INTENT(INOUT) :: LEFT, RIGHT INTEGER :: WRONG ?? IF (DEBUG_PROC_NAME) THEN PRINT *, "Entering IntSwap" ?? ENDIF ?? IF (DEBUG_PROC_ARGS) THEN PRINT *, " IntSwap(in):left = ", LEFT PRINT *, " IntSwap(in):right = ", RIGHT ?? ENDIF WRONG = RIGHT LEFT = RIGHT RIGHT = WRONG ?? IF (DEBUG_PROC_ARGS) THEN PRINT *, " IntSwap(out):left = ", LEFT PRINT *, " IntSwap(out):right = ", RIGHT ?? ENDIF ?? IF (DEBUG_PROC_NAME) THEN PRINT *, "Exiting IntSwap" ?? ENDIF ENDSUBROUTINE INTSWAP --- possible text output from conditional compilation execution --- ! EXAMPLE 2 shows a possible short file for output SUBROUTINE INTSWAP (LEFT, RIGHT) INTEGER, INTENT(INOUT) :: LEFT, RIGHT INTEGER :: WRONG WRONG = RIGHT LEFT = RIGHT RIGHT = WRONG ENDSUBROUTINE INTSWAP --=====================_853110794==_--