From david@imagine1.com Tue Mar 4 19:08:08 1997 Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id TAA01527 for ; Tue, 4 Mar 1997 19:07:55 +0100 Received: from ppp129.swcp.com (ppp122.swcp.com [204.134.0.172]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id LAA17165 for ; Tue, 4 Mar 1997 11:07:43 -0700 Date: Tue, 4 Mar 1997 11:07:43 -0700 Message-Id: <199703041807.LAA17165@kitsune.swcp.com> X-Sender: evt@swcp.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_857493634==_" To: sc22wg5 From: david@imagine1.com (David Epstein) Subject: A few words from the CoCo project editor X-Mailer: X-Attachments: C:\DE\WG5\COCO\COCOVIEW.TXT; --=====================_857493634==_ Content-Type: text/plain; charset="us-ascii" --=====================_857493634==_ Content-Type: text/plain; charset="us-ascii" Dear SC22WG5, Here is my summary of the Fortran-like conditional compilation (CoCo) and why it is needed in standard Fortran. Before this summary, a quick word about the last meeting. I have quite mixed feelings about the results of the latest X3J3/SC22WG5 joint meeting in Las Vegas. Overall, I am pleased to see such support for the Fortran-like CoCo given my absense and the general stength of the opposing vocal minority whenever a champion is unable to attend a meeting. My thanks to all those that attended the CoCo subgroup. I expect that this note will remind you of the issues that maybe went unmentioned in Las Vegas. David ---------- Conditional Compilation in Fortran ------------- {{{ I have given this sort of presentation at two meetings--an X3J3 meeting in Breckenridge and a SC22WG5 meeting in San Diego. After each presentation, a vote was taken as to whether or not conditional compilation is needed in the Fortran standard. The results were clearly YES in both cases (I don't have the exact vote count with me.) }}} CONTENTS #1 Why standard conditional compilation is needed in Fortran. #2 Alternatives to conditional compilation. #3 Why preprocessors are bad. #4 Summary. #1 Why standard conditional compilation is needed in Fortran. ------------------------------------------------------------- Fortran is an (almost) extremely portable language. There are only a few places where conditional compilation is required to obtain portability. One example is the INCLUDE line. Below are some more examples. A Real Life Example ------------------- I have written over 30,000 lines of portable Fortran! Unfortunately, my program is 30,100 lines long. The 100 lines, which begins the program, is used to set the differences between Dos, Mac, Unix and Linux. For example, the below lines are in my product: character(len=1), public :: SLASH integer, public, parameter :: DOS=1 integer, public, parameter :: MAC=2 integer, public, parameter :: UNIX=3 integer, public, parameter :: LINUX=4 integer, public :: my_system ... variable my_system is set by hand to DOS, MAC, UNIX or LINUX if (my_system == DOS) then SLASH = "\" elseif (my_system == MAC) then SLASH = ":" else SLASH = "/" endif In the above case, you see the use of a run-time variable named my_system to set another run-time variable named SLASH instead of the preferred safer below method of a CoCo variable my_system setting a PARAMETER named SLASH: ?? integer, parameter :: DOS=1 ?? integer, parameter :: MAC=2 ?? integer, parameter :: UNIX=3 ?? integer, parameter :: LINUX=4 ?? integer :: my_system = DOS ! override when porting ?? if (my_system == DOS) then character(len=1), public, parameter :: SLASH = "\" ?? elseif (my_system == MAC) then character(len=1), public, parameter :: SLASH = ":" ?? else character(len=1), public, parameter :: SLASH = "/" ?? endif Although this example is enough for me to want CoCo, there is more to the portability of my code than the above example. This next example shows a problem that cannot be overcome with the run-time variable trick used for my_system and SLASH: ! After setting SLASH, set the path for the subdir character(len=7), private, parameter :: DIR_NAME = "f_files" character(len=8), private, parameter :: & PATH_NAME = DIR_NAME // SLASH I had the above code in my product until debugging the PowerPC Macintosh version revealed that the Mac requires the SLASH both before and after the DIR_NAME (the poorly named SLASH shows that I ported to the Mac after writing this code for DOS and UNIX since the Mac uses a colon and not a slash!). In other words, a file named "foo" in the subdirectory "f_files" is referenced by :f_files:foo on the Mac, and by f_files\foo on DOS, and by f_files/foo on Unix and Linux. To fix this, I use "human CoCo" and cross my fingers that the programmer reads comments: !! ONCE COCO IS HERE, FIX THIS! Length needs to be 9 on the Mac... !!?? if (coco_system == coco_MAC) then !!!??> character(len=9), private, parameter :: & !!!??> PATH_NAME = SLASH // DIR_NAME // SLASH !!?? else ! all other systems use a length of 8 character(len=8), private, parameter :: & PATH_NAME = DIR_NAME // SLASH There may be cleaner ways to handle this. The point is, however, that only some portability issues can be "solved" using run-time variables when a PARAMETER would be more appropriate. Another Real Life Example ------------------------- One of the Interval Arithmetic papers that shows a Fortran module with a block of code commented out. I recall a comment on the top of that block mentioning that the code did not compile on a certain Fortran product, so a work around is provided below. ! The commented out block can be done with ! conditional compilation instead of putting ! exclamation marks in column one by hand! This was not found in a CoCo paper, but in an Interval Arithmetic paper ... I happen to notice it. A Real Life Document and Discussion ----------------------------------- At the San Diego SC22WG5 meeting, Tom Lahey showed me a Fortran90 book where the author mentions how unfortunate it is that the USE statement cannot be conditional. During the following SC22WG5 meeting in Dresden, a seemingly unrelated topic came around to somebody asking, "Can you make a USE statement conditional?". When somebody answered "No", I commented, "Yes ... using CoCo!" People laughed, thinking that I was putting in a plug for CoCo, but I was quite serious. Not a meeting goes by where I don't hear of an issue that would be resolved if CoCo was available. Why Standardize CoCo? --------------------- I want my 30,100 lines to be standard Fortran. Until CoCo becomes standard, I am unable to say that my code is standard. My desire to write standard code is not uncommon. The need for CoCo is so strong that there are literally dozens of solutions being used by Fortran programmers to achieve conditional compilation; most of them are home grown preprocessors. Of course, I often quote the beginning of the standard, in Section 1 where it states 1.1 Scope .. The purpose of this International Standard is to promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on a variety of computing systems. #2 Alternatives to conditional compilation. ------------------------------------------- Above, you see two alternatives to conditional compilation: (1) use run-time variables (2) rely on humans to comment and uncomment lines of code Other methods such as maintaining many different INCLUDE files are also popular (as well as error-prone) ways to obtain conditional compilation. #3 Why preprocessors are bad. ----------------------------- A preprocessor generally offers three or four features: (1) conditional compilation (2) text substitution (3) macro expansion (4) an INCLUDE facility if there is not already one in the language. Of these, only conditional compilation is desirable for Fortran (since INCLUDE is already in the language.) Preprocessor are bad because (2) and (3) are bad. Yes, I understand how C programmers like the power of (2) and (3), but these features are not safe and the evolution of C, if you believe it is Java, has shown this. At recent Fortran meetings, there have been comments and support for text substitution and macro expansion, but the implementation of these features in Fortran needs more energy and attention to define a safe definition. Thowing in these features cannot be done without first deciding on their desirability. Personally, I would strongly oppose any macro expansion, and would need to be presented with a solid approach to text substitution before considering expanding the CoCo definition. Here is an example that shows why simple text substitution, as available in cpp/fpp/any_C_like_approach is dangerous for the planet: #define MELTDOWN_POINT = 601 .. if (current_point < MELTDOWN_POINT) { /* All is ok? */ } elseif (current_point > MELTDOWN_POINT) { /* Handle extrememly dangerous value */ } else { /* Handle initially dangerous value */ } The above is C ... possible problems are worse for Fortran. If you prefer, consider MELTDOWN_POINT to be a value related to the wings of the next airplane you are going to fly on. The bug? My guess is that at least one person out there does not see the problem with the above "text substitution". Even C programmers can get caught on this. The problem is that the definition of MELTDOWN_POINT is not suppose to have an equals sign in it. Since Fortran programmers are often more interested in solving their problems than in the list of pitfalls to avoid, I strongly encourage the Fortran world to put off the idea of offering standard text substitution until its desirability becomes clear. Here is another example, slightly different, this time done in Fortran and mixed with cpp: #define MELTDOWN_POINT 601 ! Danger at this point integer, parameter :: VERY_DANGEROUS = MELTDOWN_POINT + 10 The bug? Again the problem is with the definition of MELTDOWN_POINT ... it has a comment in it. DID I IGNORE TEXT SUBSTITUTION AND MACROS IN THE COCO DEFINITION? ----------------------------------------------------------------- While defining CoCo, I needed to fend off some strong feelings on the CoCo development body that the character type be added to integers and logicals. We reserved the character type for possible future extensions such as text substitution and macro expansion. Consider how the above bug is no longer likely once it is seen in a Fortran-like definition using character variables. The cpp/fpp approach: #define MELTDOWN_POINT 601 ! Danger at this point A possible Fortran-like approach: ?? character (len=3) :: MELTDOWN_POINT = "601" ! Danger at this point #4 Summary. ----------- 1. Fortran needs a standardized conditional compilation language suitable for Fortran programmers. 2. Alternatives to a standardized conditional compilation language are unsafe and nonportable. 3. The word "preprocessor" often refers to a number of features, of which, most are undesirable or contraversial at best. I use the word preprocessor in the CoCo document simply because I was told it would make the paper more understandable. The CoCo definition does not require a preprocessor implementation. 4. After all this work, dropping CoCo would mean ignoring the words so eloquently promised in Section 1.1 of the Fortran standard. --=====================_857493634==_--