From eeccee@mixcom.com Mon Mar 27 .:05:13 1995 Received: from mixcom.mixcom.com by dkuug.dk with SMTP id AA11075 (5.65c8/IDA-1.4.4j for ); Wed, 29 Mar 1995 03:43:33 +0200 Received: by mixcom.mixcom.com (8.6.10/2.2) id BAA04621; Wed, 29 Mar 1995 01:37:14 GMT Message-Id: <199503290137.BAA04621@mixcom.mixcom.com> Subject: CCF Proposal by David Epstein (X3J3/93-276) To: sc22wg5@dkuug.dk (WG5 Mailing List) Date: Tue, 28 Mar 1995 19:37:13 -40975532 (CST) From: "Craig Dedo" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 25419 X-Charset: ASCII X-Char-Esc: 29 Dear Members of WG5 Mailing List, Following is a copy of David Epstein's Conditional Compilation Facility (CCF) proposal. He presented this to the November 1993 X3J3 meeting which was held in Albuquerque, NM. It was assigned document number X3J3/93-276. At the time, David Epstein was an employee of IBM. He now an independent consultant in Bend, OR. I scanned this off of the paper copy which was presented at the meeting. I am providing this copy as a courtesy for those who may not have seen it yet. [Begin David Epstein's CCF Proposal] To: X3J3 From: David Epstein IBM Corporation X3J3/93-276 e-mail: epstein@stlvm20.vnet.ibm.com phone: 408-463-4423 Subject: Conditional Compilation Facility !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! OUTLINE !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ Rationale --------- The idea. Why conditional compilation for Fortran? Why CCF instead of other alternatives? Conditional compilation and preprocessor history in Fortran. The minimal usable language. CCF everywhere. Definition ---------- CCF Definition - Summary CCF Definition - Detailed Definition CCF Definition - One Source File CCF Definition - CCF File CCF Definition - Usability Constraints Questions and Answers --------------------- Why not text-substitution? Why not provide CCF character type? Why not allow CCF named constants? Why not recognize include? Why not CASE construct? Why not implicit type declarations? CCF File Example ---------------- Previous Art (Bibliography) --------------------------- !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! RATIONALE !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ Rationale --------- a. The idea. CCF is based on the idea of using Fortran-like syntax for a Fortran preprocessor language. b. Why conditional compilation for Fortran? For Fortran to become the multiple platform programming language of choice, conditional compilation must be available. Programmers choosing a language for a portable application could choose C/C++ over Fortran simply for the reputation of C/C++ as being portable. With conditional compilation in Fortran, it becomes a stronger candidate for writing portable programs. c. Why CCF instead of other alternatives? ALTERNATIVE-1: Call cpp and send cpp output into Fortran ???????????????????????????????????????????????????????? AVAILABILITY cpp is available and can always be used to preprocess a file. ADVANTAGES The C preprocessor (cpp) language is more powerful than CCF. cpp has text-substitution, a macro facility, and it's own include line. DISADVANTAGES The cpp language tests if a variable is defined, introducing the "mispell" problem of defining a name on the command line or in the source and mispeling it in the IF statement. This "user bug" is often difficult and time consuming to find. The cpp language is not Fortran. I have followed public fora notes discussing conditional compilation, preprocessors, and the use of cpp for Fortran for over three years. There have been many discussions on the pitfalls of using the cpp for Fortran and a couple of alternatives to using cpp have surfaced. The use of cpp for Fortran appears based on availability and popularity today of C. The basic problem is that C is not Fortran; the specific problem is that Fortran programmers do not care what a C comment looks like today or in the future. The introduction of the C "//" comment has only made this hole more likely for the Fortran programmer to fall into. The C "/*", "*/" comment has always been a problem for Fortran programmers using cpp. For example ! ! The following, when run thru cpp gave a warning about the ! size of a character constant on line 14. Why not line 10? ! !234567 logical pepples pepples = .false. ! start a C comment, /* if (pepples) then print *, 'look out for difference btw l= and /=' ! line # 10 endif pepples = .true. ! end C comment, */ if (pepples) then print *, 'because I know how to spell elif' ! line # 14 endif end The output, from cpp, shows that the C comment has vanished ! ! The following, when run thru cpp gave a warning about the ! size of a character constant on line 14. Why not line 10? ! !234567 logical pepples pepples = .false. ! start a C comment, if (pepples) then print *, 'because I know how to spell elif' ! line # 14 endif end Fortran programs can be written to use cpp; it is more difficult and error prone to add cpp usage to already existing Fortran programs. ALTERNATIVE-2: Use a Fortran-like cpp ????????????????????????????????????? ADVANTAGES The cpp language is more powerful than CCF. The cpp language has text-substitution, a macro facility, and it's own include line. DISADVANTAGES How similar is a Fortran-like cpp to the actual cpp? Does it use "!=" or "/=" ? Does it use "elif" or "elseif"? Does it use "THEN" in the IF statement? The cpp language tests if a variable is defined, introducing the "mispel" problem of defining a name on the command line or in the source and mispelling it in the IF statement. This "user bug" is often difficult and time consuming to find. d. Conditional compilation and preprocessor history in Fortran. Many languages have added conditional compilation. Many Fortran implementations have added D-lines, conditional include, subsets of cpp, and other conditional compilation languages to the Fortran language. Many Fortran preprocessors added features which later became part of the Fortran language (longer variable names, do loops, etc.). More recent Fortran preprocessors aid in optimizing Fortran code. Some Fortran preprocessors, written in Fortran, provide conditional compilation. The most recent Fortran preprocessors "clean-up" old Fortran code. Some Fortran preprocessors are: RATFOR, EXPAND, ASPIRIN, FORSE, MORTRAN, CASUAL, VAST, KAP m4, bpp Two Fortran preprocessors that offer conditional compilation and are written in Fortran are: FPP - Adam Boyarski ANB@SLACVM.SLAC.Stanford.EDU CMDC - Ron Shepard(?) shepard@tcg.anl.gov e. The minimal usable language. The Fortran community will one day desire more power than the existing language supplies. This cycle of introducing new features, followed by public requests for more features, then returning to introducing new features is workable. The definition of CCF takes into account the way things work. Someday text substitution and macros might exist in the language. A goal of the design of CCF is to not prohibit a future preprocessor language. This goal is achieved by keeping CCF simple and small. A future Fortran macro language may very well be it's own facility, completely separate from CCF. While keeping CCF simple and small, caution is used to not cripple usability. The minimal language would simply be an IF statement and an END IF statement. A natural step is to provide an ELSE IF and an ELSE statement. The desire to solve the cpp "mispel" problem drives the introduction of the INTEGER and LOGICAL statements. PRINT and STOP statements are usability requests of customers. Initialization on the command line removes the requirement of editing source. Commenting and uncommenting source lines allows single file maintenance. f. CCF everywhere. The power of availability is not to be underestimated. Once everyone has CCF, improvements will naturally occur. Since CCF is mostly Fortran syntax, adding CCF into a Fortran processor is simplified by reusing existing code. Testing the logic of CCF can be done with the aid of a simple Fortran program that removes the "!CCF$" from CCF statements and places non-CCF statements into an output statement. Definition ---------- a. CCF Definition - Summary 0) CCF statements all begin in column 1 with "!CCF$" in both free and fixed source forms. 1) Declare CCF variables using INTEGER and LOGICAL statements. a) Not initialized o !CCF$ INTEGER :: example o !CCF$ LOGICAL :: debug b) Initialized o !CCF$ INTEGER :: example = 3 o !CCF$ LOGICAL :: debug = .true. 2) CCF expressions contain: o CCF variables o CCF integer constants and CCF logical constants o CCF operators: Unary: +, -, .NOT. Binary: +, =, *, /, .EQ., .NE., ==, /=, .LT., .LE., .GT., .GE., <, <=, >, >=, .AND., .OR., .EQV., .NEQV. o parenthesis 3) Assign values to CCF variables o In CCF INTEGER or LOGICAL statement o In CCF assignment statement !CCF$ example = 33 !CCF$ debug = .false. o Compiler option, for example CCFSET(example=44) 4) IF construct o !CCF$ IF (logical CCF expr) THEN o !CCF$ [ ELSEIF (logical CCF expr) THEN ] ... o !CCF$ [ ELSE ] o !CCF$ ENDIF 5) Usability statements o !CCF$ PRINT * [, character-constant |, CCF expression ] ... o !CCF$ STOP [ character-constant | upto5-digit-string ] b. CCF Definition - Detailed Definition 0) CCF statements begin in column 1 with "!CCF$" in both free and fixed source forms. The "ccf" is case-insensitive. For blanks, the Fortran free source form rules apply. CCF does not require that a CCF processor flag the use of fixed source form rules for blanks. CCF statements can span more than one line by using continuation lines. Continuation lines of a CCF statement must begin in column 1 with "!CCF$". Continuation rules are otherwise the same as the source form of the file. The following is an example in fixed form: !234567 !ccf$ print *, !ccf$x'Hey Dino, this is a continued CCF statement' 1) Declare CCF variables using INTEGER and LOGICAL statements. Kind parameters and entity attributes are not allowed. CCF variables must be scalar. The initialization value must be a CCF expression. 2) CCF-expr is CCF-unary-op CCF-primary or CCF-primary [ CCF-binary-op CCF-primary ] CCF-primary is CCF-constant or CCF-variable or ( CCF-expr ) CCF-constant is CCF-int-constant or CCF-log-constant CCF-int-constant is [sign] int-constant sign is + or - CCF-log-constant is .TRUE. or .FALSE. CCF-variable is CCF-int-variable or CCF-log-variable CCF-unary-op is CCF-unary-arith-op or CCF-unary-log-op CCF-unary-arith-op is + or - CCF-unary-log-op is .NOT. CCF-binary-op is CCF-binary-arith-op or CCF-binary-equal-op or CCF-binary-rel-op or CCF-binary-log-op CCF-binary-arith-op is + or - or * or / CCF-binary-equal-op is .EQ. or .NE. or == or /= CCF-binary-rel-op is .LT or .LE or .GT. or .GE. or < or <= or > or >= CCF-binary-log-op is .AND. or .OR. or .EQV. or .NEQV. Constraint: A CCF-unary-op or a CCF-binary-op must not be followed by a signed CCF-int-constant. Constraint: There are no implicitly typed CCF variables; therefore, a CCF variable must be declared in a CCF INTEGER or CCF LOGICAL statement. Constraint: A CCF variable must have been assigned a value before it can appear in a CCF expression. 3) Assign values to CCF variables Constraint: All values assigned to CCF variables must match the type of the CCF variable. o A CCF variable can be initialized in a CCF INTEGER or CCF LOGICAL statement. o A CCF variable can be assigned a value in a CCF assignment statement. o A CCF variable can be initialized with a compiler option. This initial value would replace any initial value specified in a CCF INTEGER or CCF LOGICAL statement; however, it would not replace a value assigned in a CCF assignment statement. An initialization using a CCF compiler option might look like: CCFSET=example:44 4) Conditional blocks There are no construct names in a CCF IF construct. 5) Usability statements The CCF PRINT statement can contain character constants and CCF expressions. The only form of the CCF PRINT statement is list-directed. The CCF STOP statement can contain a character constant or a five-digit integer. A CCF STOP statement halts CCF processing as long as it is not in a .FALSE. branch of a CCF IF construct. c. CCF Definition - One Source File Ideas from other preprocessors have guided the CCF definition. In particular, Ron Shepard's CMDC introduced me to the idea of allowing the preprocessor to write over the original source without loss of information. Maintaining two files, the original and the preprocessed, is often annoying and dangerous. CCF produces a file that can replace the original source file. Whereas some preprocessors convert source lines to comments, CCF goes one step further -- CCF will "uncomment" a line that was previously converted to a comment. After the initial run through CCF, the file would only need to be run through CCF again when changing the value of a CCF variable. d. CCF Definition - CCF File If maintaining the number of lines is desired, the CCF file will differ from the input file only where non-CCF lines exist inside a CCF IF construct: .FALSE. part: The lines in the .FALSE. part(s), if any, will contain either "!CCF>" or "!CCF*" in columns 1-5. If the line contains "!CCF>", the rest of the line is the original line shifted right 5 characters if the original line did not already contain "!CCF>" in columns 1-5. An option specifies whether to use "!CCF*" or "!CCF>". .TRUE. part: The lines in the .TRUE. part, if any, could be different than the line from the original source if the original source contained either a "!CCF>" or "!CCF*" in columns 1-5. If the original line contains "!CCF>" the new line removes the "!CCF>" and shifts the rest of the line left 5 characters. If the original line contains "!CCF*" in columns 1-5, the new line has blanks in columns 1-5 and the rest of the line remains the same. If maintaining the number of lines is not desired, the CCF file will only contain the non-CCF lines that are not in the .FALSE. part of a CCF IF construct. e. CCF Definition - Usability Constraints The following is a list of usability constraints: 1) The data type of a command line initial value must match the type of the CCF variable declared. 2) Initial value on the command line must be a CCF-int-constant or T, t, F, or f. 3) If a CCF variable is initialized on the command line, the CCF variable must be declared ln the source. 4) A non-blank character must not appear in columns 1 to 5 of an ignored line when a CCF file is created using the NOSHIFT option. In particular, the characters "!CCF>" in columns 1 to 5 must be reported as a previously shifted CCF file being converted to a non-shifted CCF file. 5) A non-blank character must not appear in columns 68 to 72 of an ignored line when a CCF file is created using the SHIFT option. 6) If a CCF variable is initialized on the command line, the variable must either be o initialized in a CCF INTEGER or CCF LOGICAL statement or o used before appearing on the left in a CCF assignment statement. DISCUSSION: Prevent the mistake of thinking that the command line value overrides a CCF assignment statement value. END DISCUSSION !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! QUESTIONS & ANSWERS !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ Questions and Answers --------------------- a. Why not text-substitution? If there were no column rules in Fortran (no fixed source form and no limit of 132 columns in free source form), the only delay in offering text-substitution would be designing the definition. Text-substitution is valuable. Some Fortran programmers require text-substitution, and are using cpp or another preprocessor. The test of time has shown, however, that offering text-substitution in Fortran is not worth the headache. Fortran products that, at one time, offered text-substitution are now discouraging its use. b. Why not provide CCF character type? Supplying the character data type might make some CCF statements more readable. For example: !CCF$ integer:: pc !CCF$ integer:: mini = 2 !CCF$ integer:: mammoth = 3 !CCF$ integer:: machine = 1 !CCF$ lf (machine == pc) then include 'mydir\myfile.dat ' !CCF$ else if (machine == mini) then include '/mydir/myfile.dat ' !CCF$ else if (machine == mammoth) then include 'myfile dat a' !CCF$ else !CCF$ print *, 'Set "machine" to "pc" or "mini" or "mammoth"' !CCF$ stop 1 !CCF$ end if could be written as: !CCF$ character ( len=30 ) :: machine = ' pc ' !CCF$ if (machine == 'pc' ) then include 'mydir\myfile.dat' !CCF$ else if (machine == 'mini' ) then include '/mydir/myfile.dat' !CCF$ else if (machine == 'mammoth' ) then include 'myfile dat a' !CCF$ else !CCF$ print *, 'Set "machine" to "pc" or "mini" or "mammoth"' !CCF$ stop !CCF$ end if Adding the character data type does not add any functionality to CCF. It would be easier to add the character type into CCF than to take it away. Given that a full macro language for Fortran has not yet been standardized, saving the character type may aid this definition. c. Why not allow CCF named constants? It is desirable to add the PARAMETER attribute to CCF. This would be the only entity attribute in CCF. This does not mean adding a PARAMETER statement. With named constants, the above example could become: ! allowing named constants !CCF$ integer, parameter :: pc = 1 !CCF$ integer, parameter :: mini = 2 !CCF$ integer, parameter :: mammoth = 3 !CCF$ integer :: machine = pc CAVEATS: o Would it be confusing that named constants could not be used as a command line value? o Would it be confusing that a CCF PARAMETER statement was not available? o Could named constants be given a value on the command line? For example: CCFSET(pc=l,mini=2,mammoth=3,machine=pc) If this was allowed, must the value match the value in the declaration statement? d. Why not recognize include lines? Expanding includes will make the portability of separate files difficult. e. Why not CASE construct? Although the CASE construct is usable, offering a CCF CASE construct would break away from offering the minimal usable language. CCF is usable without the CASE construct. f. Why not implicit type declarations? One objective of CCF is to solve the "misple" problem of mispelling a preprocessor variable on the command line. Allowing implicitly typed variables would make this objective unattainable. !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! CCF FILE EXAMPLE !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ ORIGINAL SOURCE: !234567 !CCF$ integer :: pc = 1 " / / !CCF$ integer :: mini = 2 !CCF$ integer :: mammoth = 3 !CCF$ integer :: machine = 1 !CCF$ if (machine == pc) then include 'mydir\myfile.dat' !HPF$ !CCF$ else if (machine == mini) then include '/mydir/myfile.dat' !HPF$ "an mini HPF directive> !CCF$ else if (machine == mammoth) then include 'myfile dat a' !HPF$ "an mammoth HPF directive> !CCF$ else !CCF$ print *, 'Set "machine" to "pc" or "mini" or "mammoth"' !CCF$ stop 1 !CCF$ end if OUTPUT FROM CCF: !234567 !CCF$ integer :: pc = 1 !CCF$ integer :: mini = 2 !CCF$ integer :: mammoth = 3 !CCF$ integer :: machine = 1 !CCF$ if (machine == pc) then include 'mydir\myfile.dat' !HPF$ "a pc HPF directive> !CCF$ else if (machine == mini) then !CCF> include '/mydlr/myfile.dat' !CCF> !HPF$ !CCF$ else if (machine == mammoth) then !CCF> include 'myfile dat a' !CCF>!HPF$ "an mammoth HPF directive> !CCF$ else !CCF$ print *, 'Set "machine" to "pc" or "mini" or "mammoth"' !CCF$ stop 1 !CCF$ end if !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! PREVIOUS ART !!!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!! !CCF$ !CCF$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !CCF$ o "A Standard Fortran Preprocessor" Jeanne Martin July 13, 1990 o FPP Adam Boyarski o CMDC Ron Shepard o "The Programming Language EFL" S. I. Feldman Programmer's Manual for UNIX System III, Volume 2B o Bardiaux, M. and Delhaise, P., "Step-by-step Transition from Dusty-deck FORTRAN to Object-Oriented Programming", 1989 o Brown, P. J., MACRO PROCESSORS and Techniques for Portable Software, John Wiley & Sons, Ltd., 1974 o Cook, A. James, "MORTRAN3 User's Guide" o Dolotta, T. A., Haight, R. C. and Piskorik, E. M., "RATFOR - A Preprocessor for a Rational FORTRAN", 1977 o Feldman, Stuart I., "Papering Over Deficiencies in Your Language for Convenience and Portability: Preprocessors vs. Standards", 1984 o Johnson, A. S., "FORTRAN PREPROCESSORS", 1987 o Meyers, Eugene W. Jr. and Osterweil, Leon J., "BIGMAC II: A FORTRAN LANGUAGE AUGMENTATION TOOL", 1981 o Rice, John R., "LANGUAGE INDEPENDENT PROTRAN", 1986 o Rice, Lee C., "THE RATFOR ENVIRONMENT: STRUCTURED FORTRAN AND PORTABILITY", 1989 o Vanderbilt, M. Daniel, "BASIC Pre- and Post-processors for FORTRAN Programs", 1987 o Wetherell, Charles, "LWG FORTRAN MANUAL", 1982 o CONVEX Computer Corporation, CONVEX FORTRAN Language Reference Manual, 1989 o IEEE, P1003.9 FORTRAN 77 Bindings / DRAFT 8, 1990 o IBM, ORACLE FORTRAN Precompiler User's Guide, 1989 o IBM, VS Pascal Language Reference Release 2 1988 o IBM, VS Pascal Application Programming Guide Release 2 1988 o IBM, OS PL/I Version 2 Programming: Language Reference 1988 o IBM, OS PL/I Version 2 Programming Guide 1988 [End David Epstein's CCF Proposal] Sincerely, -- Craig T. Dedo Internet: Craig.Dedo@mixcom.com Elmbrook Computer Services Voice Phone: (414) 783-5869 17130 W. Burleigh Place Brookfield, WI 53005 Disclaimer: These opinions are mine alone. USA They do NOT represent any organization. "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin