From Keith.Bierman@eng.sun.com Wed Apr 1 02:32:37 1995 Received: from Sun.COM (koriel.Sun.COM) by dkuug.dk with SMTP id AA03054 (5.65c8/IDA-1.4.4j for ); Wed, 29 Mar 1995 20:33:24 +0200 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (koriel.Sun.COM) id AA29115; Wed, 29 Mar 95 10:32:06 PST Received: from chiba.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AA01216; Wed, 29 Mar 1995 10:33:11 -0800 Received: from localhost by chiba.Eng.Sun.COM (4.1/SMI-4.1) id AA29187; Wed, 29 Mar 95 10:32:39 PST Message-Id: <9503291832.AA29187@chiba.Eng.Sun.COM> To: jamie@zfatal.cern.ch (Jamie Shiers) Cc: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.781) Conditional Compilation In-Reply-To: Your message of "Wed, 29 Mar 95 09:50:56 +0200." <199503290751.AA18149@dkuug.dk> Date: Wed, 29 Mar 95 10:32:37 PST From: Keith.Bierman@eng.sun.com X-Charset: ASCII X-Char-Esc: 29 >I have so far avoided joining the conditional compilation >fray, but all good things must come to an end... Me too ;> If my memory serves, rpc added the ".F" processing (that is run cpp on the source before compilation) to the "unix f77" (aka the sif compiler) well over a decade ago (it was, of course, supposed to be a temporary hack whilst an fpp was crafted). As best I can tell every Sun f77 release supported .F processing. From time to time, we've made motions to remove it, and our customers make it clear that is an unacceptable decision. The objections to cpp seem to fall into the following wide categories: 1) Some people (and not necessarily a small number) would prefer a "Fortran" look and feel. Counterargument: existing practice. 2) As C and C++ implementors well know, cpp semantics get in the way of of various compile speed optimizations. Counterargument: existing practice. 3) cpp does evil things to my code when I use macros. As Epstein pointed out, a vendor solved this by making their preprocessor not expand macros in Fortran code. Unfortunately, we have many customer who actually write such macros (we know because from time to time they get into trouble and file a bug report ;>). So we are going to have to cope (sun). There are obvious solutions, and I will see what I can do to get the details published in advance of our implementation showing up in a product release. Since we (sun) are going to support something that looks and feels almost completely like cpp (to keep our existing customers placated) and having two such facilities is hardly attractive, I am opposed to any proposal which isn't compatible with the existing Fortran user usages of cpp; or which adds significantly different syntax. Note that there have been many other preprocessors (including commerical implementations such as Lahey's). None has stood the test of time as well, nor has as many current users as cpp(like). This is not an area in which innovation is useful.