From hirchert@ncsa.uiuc.edu Mon Feb 12 15:33:10 1996 Received: from newton.ncsa.uiuc.edu (newton.ncsa.uiuc.edu [141.142.2.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id PAA11232 for ; Mon, 12 Feb 1996 15:33:05 +0100 Received: from space.ncsa.uiuc.edu (space.ncsa.uiuc.edu [141.142.4.10]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id IAA17723 for ; Mon, 12 Feb 1996 08:32:48 -0600 Received: (from hirchert@localhost) by space.ncsa.uiuc.edu (8.6.11/8.6.11) id IAA18215 for SC22WG5@dkuug.dk; Mon, 12 Feb 1996 08:32:47 -0600 Message-Id: <199602121432.IAA18215@space.ncsa.uiuc.edu> From: hirchert@ncsa.uiuc.edu (Kurt W. Hirchert) Date: Mon, 12 Feb 1996 08:32:47 -0600 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: SC22WG5@dkuug.dk Subject: X3J3 Liaison Report on Conditional Compilation X3J3/96-048r2 (Page 1 of 1) 1996 Feb 08 To: WG5, X3J3, and David Epstein From: X3J3/oof Subject: Liaison Report on Conditional Compilation Reference: CoCo straw 2 (X3J3/96-035) We are generally satisfied with X3J3/96-035 as the approach to the "Fortran-like" alternative, but note the following specific concerns: o We believe that ?STOP is the wrong concept; suppressing further CoCo processing after the detection of an error will prevent the immediate detection of further errors in CoCo, leading to an inefficient "one at a time" process of detecting and correcting CoCo errors. We suggest that "Fortran-like" does not require that every CoCo statement have an exact analog in Fortran, and that in this case, what is needed is some mechanism for noting that an error has been detected, so that processing may be halted at the end of CoCo processing. o We are concerned that in large programs (produced by multiple programmers), the proposed rule for duplicate names may cause unnecessary problems as applied to "temporary" CoCo variables that are not to be set from the command line. We suggest that some convenient means of resolving these conflicts (e.g., the option for "local" scoping) may be in order. o We note that there seems to be a mismatch in the handling of command line values and variables without a declared initialization. Because of that lack of initialization, it appears that either the command line value will be ignored (because an assignment precedes the first reference) or that the program will be erroneous in the absence of a command line value (because no assignment precedes the first reference and the variable is still undefined at that point). Some adjustment of the rules may be in order, e.g., . allowing command line values to be specified only for those variables that have been given initial values, . requiring all variables to be given initial values, or . defining a default initial value (such as 0 for integers and .false. for logicals) for all variables not explicitly initialized. o There is no mention of allowing comments in CoCo. We suggest that both end of line and full line comments are desirable. (If CoCo is used to control variants of files other than Fortran source, there is significant difference between a CoCo full line comment (thrown away during CoCo processing) and an ordinary Fortran comment.) o We note that construct names could be useful when variant text segments are long, but end of line comments are probably an adequate, if less than ideal, replacement. o The description of ?IF should explicitly say that it can be nested. o The description of expressions in CoCo does not allow for the use of CoCo variables. (We assume this is an unintended oversight.) We are concerned that there has been no visible progress in the area of the "cpp-like" alternative since the last meeting. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications