From david@imagine1.com Fri Jul 12 06:19:47 1996 Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id GAA09740 for ; Fri, 12 Jul 1996 06:19:44 +0200 Received: from ppp114.swcp.com (ppp97.swcp.com [204.134.0.207]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id WAA16101; Thu, 11 Jul 1996 22:19:34 -0600 Date: Thu, 11 Jul 1996 22:19:34 -0600 Message-Id: <199607120419.WAA16101@kitsune.swcp.com> X-Sender: evt@swcp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Miles.Ellis@etrc.ox.ac.uk (Miles Ellis) From: david@imagine1.com (David L. Epstein) Subject: CoCo paper for Dresden Cc: sc22wg5@dkuug.dk X-Mailer: Miles, Please give the below paper from John Prentice a number for the Dresden meeting. Thanks, David ------------------------------------------------------------------- To: SC22WG5 From: David Epstein Subject: CoCo email from John Prentice Greetings all. In advance of the upcoming WG5 meeting, I want to throw out my preference regarding whether to adopt the Fortran-like CoCo that David Epstein has been pushing for several years, or adopt the Sun like fpp CoCo, basically a warmed over version of the C cpp preprocessor. I have been using Fortran preprocessors for 24 years, starting back in the dark ages when we had to write our own because nothing was out there in general distribution. During that time, I have extensively used quite sophisticated, but home grown preprocessors, I have used the C cpp preprocessor, and I have carefully followed and experimented with Epstein's Fortran-like preprocessor. We are currently using condition-compilation in our Zapotec code, one of the main application codes in the DoE Accelerated Strategic Computing Initiative (it is a coupled Eulerian/Lagrangian solid dynamics hydrocode that was developed by Quetzal in conjunction with Sandia National Laboratory and Alliant Techsystems Incorporated). This Fortran 90 code implements a domain decomposition scheme to time-dependently couple the Eulerian CTH hydrocode to either the EPIC or the Pronto Lagrangian hydrocodes. The limited memory available on many MPP processors necessitates that we employ conditional compilation so that in a given executable we are either coupling CTH and EPIC or CTH and Pronto. We also use conditional compilation to deal with incompatibilities between parallel machines and non-parallel machines. Because of dissatisfaction with cpp/fpp, we have implemented a simple preprocessor in Fortran 90 to do some of the very simplest stuff in the current Fortran-like CoCo definition. We intend like to use this conditional- compilation capability at a more sophisticated level in the future. Therefore, we would very much like to see it part of the Fortran standard and supplied as part of standard conforming compilers. We strongly favor adoption of a Fortran-like preprocessor over a cpp/fpp like preprocessor. I am loath to use cpp for Zapotec or any other large code development project. There are many reasons, some are simply personal preference based on having used cpp for years and having run into alot of limitations and frustrations that the Fortran-like CoCo nicely addresses. Other reasons are less subjective and have to do with how easy it is to introduce errors when using cpp. Probably the thing I most dislike is the fact that one can so trivially mess up a cpp identifier or token and generate unintended consequences. When you have a dozen people working on a source code, many of whom may not be extremely familiar with the details of the code and all of whom are error-prone humans, this can lead to lots of problems. It is especially easy to simply misspell an identifier, leading to interesting problems. We also favor the Fortran-like CoCo because the syntax is Fortran-like. We don't want someone to have to learn a new syntax and set of language constructs just to be able to interpret or use conditional compilation in one of our codes, that leads to errors and it is inefficient. The value of consistency between the constructs and syntax of the conditional compilation and the language itself seems apparent to us for big applications codes in the real world. Do you really want Fortran programmers to have to know that they use .AND. for the language, but something like & for the conditional-compliation facility? Or what about continuation characters? They are different between cpp and Fortran 90. Bottom linke, we urge WG5 to adopt the proposed Fortran-like CoCo definition. It is well thought out, it is sophisticated, and it is consistent with the syntax and constructs of the language. Regards, John --- Dr. John K. Prentice President, Quetzal Computational Associates, Incorporated 3455 Main Avenue, Suite 4, Durango, CO 81301-0201 USA Phone: 970-382-8979 Fax: 970-382-8981 E-mail: john@quetzalcoatl.com WWW page: http://swcp.com/~quetzal/quetzal.html