From maine@altair.dfrc.nasa.gov Mon Jan 27 22:34:58 1997 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA23034 for ; Mon, 27 Jan 1997 22:34:49 +0100 Received: by altair.dfrc.nasa.gov (SMI-8.6/SMI-SVR4) id NAA13476; Mon, 27 Jan 1997 13:34:20 -0800 Date: Mon, 27 Jan 1997 13:34:20 -0800 Message-Id: <199701272134.NAA13476@altair.dfrc.nasa.gov> From: Richard Maine To: Larry Rolison cc: sc22wg5@dkuug.dk Subject: (SC22WG5.1270) Informal Review of Source Processing Draft Standard In-Reply-To: <199701272024.VAA22705@dkuug.dk> References: <199701272024.VAA22705@dkuug.dk> Mime-Version: 1.0 (generated by tm-edit 7.92) Content-Type: text/plain; charset=US-ASCII Larry Rolison writes: > ---------------------------------------------------------------------------- > > Informal Ballot on N1247 (Draft Standard for Source Processing in Fortran) > > ____________ > I believe that the current draft should supplant | | NO | > the current "Fortran-like" model in all further | | | > considerations of source processing ("conditional ------------ > compilation") The main reasons are the same ones that have caused me to prefer the Fortran-like approach all along, namely 1. I don't like introducing C expression syntax into the Fortran standard. If I liked C expression syntax, I'd be using C. I believe it introduces confusion to mix the two in the same source file. 2. I have long considered the #ifdef construct and its relatives to be a horribly designed feature in that it is extremely error prone. It is inherently vulnerable to typos. If you mistype the name, either in the #define or the #ifdef, then you just get the wrong result - no error message. Even getting the case of a letter wrong will mess you up, or mistyping O for 0. I've made such mistakes with cpp more than once myself, and I've helped other people debug when they made it. I am opposed to copying this misfeature. I much prefer to see something like in the Fortran language (or for that matter the C language), where you test the value of variables instead of testing whether the variable is defined or not. Fine-tuning the document isn't likely to change these objections, as these "features" are pretty much inherent in the approach. I'd rather see pre-processing dropped than to copy what I regard as several of the mistakes of cpp (even though the proposal does fix some of cpp's other mistakes, if I recall). > (signed) Richard Maine > > (date) 27 Jan 97