From Keith.Bierman@Eng.Sun.COM Thu Aug 22 22:13:23 1996 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA02828 for ; Thu, 22 Aug 1996 22:13:19 +0200 Received: by mercury.Sun.COM (Sun.COM) id NAA28174; Thu, 22 Aug 1996 13:12:36 -0700 Received: from chiba.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08187; Thu, 22 Aug 1996 13:12:17 -0700 Received: from chiba by chiba.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA11968; Thu, 22 Aug 1996 13:12:07 -0700 Message-Id: <199608222012.NAA11968@chiba.eng.sun.com> To: Miles.Ellis@etrc.ox.ac.uk (Miles Ellis) cc: sc22wg5 Subject: Re: (SC22WG5.1162) Review of N1192 - Conditional Compilation (Part 3) In-reply-to: Your message of "Wed, 21 Aug 1996 18:23:29 BST." <199608211725.TAA06905@dkuug.dk> Date: Thu, 22 Aug 1996 13:12:05 -0700 From: Keith Bierman QED I believe that N1192 is ready for submission | | to SC22 for balloting as a Committee Draft |_____| for Part 3 of the Fortran Standard | NO | |_____| Even if we really want to go down this path, COCO as currently written doesn't have features that experience has taught us customers *require* (e.g. macro expansion). So the draft is, at best, incomplete. Of course, I still maintain that we ought not do this at all (having researched the topic for the last year or so, on and off) because: * preprocessors/conditional compilation does not solve the portability problem(s), instead they paper over such problems. * Complicate the programming environment (debuggers, browsers etc.) * Complicate the compilation system (interferes with program database/whole program compilation, various acceleration schemes) * Newer languages depreciate their use (e.g. C++) or avoid them entirely (e.g. Java). Experience has taught us that they are an inappropriate solution. If we are to do it anyway, the imperative of Standardization is to cannonize existing practice. So we ought to use an "fpp" approach * Cannonize most prevalent existing practice * Remove worst warts of "cpp" as a Fortran processor * Extensive usability testing resulted in keeping more cpp than expected. Standardization of "coco" will have the unfortunate effect of creating *more* dialects of preprocessor, not fewer. Opposite the effect Standardization is supposed to produce. This comes about because: * History suggests that old preprocessors don't get abandoned. Any large project that uses one now, will continue to use the same one indefinitely. * Vendors have to continue to support what they have now. Virtually all Unix and Unix style vendors support cpp now. * Unless a miracle occurs, some vendors will implement and integrate COCO at different rates. Thus each user will have to choose between fully integrated "c/fpp" and user-hosted or partially supported COCO. Increasing the number of dialects of preprocessor will likely erode confidence in ISO standards in general, Fortran standards, and most particularly parts of the standard other than -1. In addition, vendors (and to a lessor extent users) will be diverted from working on more important things (e.g. f95, performance, programming environment work, etc.) which cannot be good for the future of Fortran as a viable environment. Signed: Keith H. Bierman.......................... Date: ..8/22/96 Country: USA.................................. This is an individual vote On a related note, fpp (including C source code) is being made publically available. I have just finished the submission to netlib. When I know the final location, I'll send a brief announcement to the list.