dgh%dgh@Sun.COM (David Hough) (02/20/88)
The Fortran draft public comment period is about to close and the C comment period is about to open. comp.lang.c readers who've been irritated by suggestions that C could learn some things from Fortran might be slightly surprised to learn that I suggest that Fortran could borrow from C as well. The following excerpts from the Fortran comments I'm writing relate to C. Comment #5, Section 3.3: Source form and significant blanks The Draft should only standardize the modern free-form source format with significant blanks, so that newly written Fortran programs will reflect the progress in programming language design since Algol-60. In addition, to take care of the vast amounts of code in dusty decks, the Draft should require that an implementa- tion provide means whereby any valid Fortran-66 or Fortran- 77 program can be translated automatically to a valid For- tran 8x program in the free-form source format. I expect that a public-domain implementation of such a translator would soon become available; a preprocessor ought to be incorporated into the standard anyway as discussed next. Comment #6, Section 3.3: C preprocessor and #include One common complaint about the Draft is that is does not provide an include-file mechanism; a response is that include-files are no longer necessary for common definitions and the like because of the new module interface facility. Both the complaint and the response are over-simplified and could perhaps be easily resolved if it was more gen- erally recognized in the Fortran community that most large scientific computing sites have at least some systems with a tool installed called the C preprocessor, sometimes provided as part of a C compiler, sometimes separately. Its defini- tion is currently being standardized by X3J11. An implemen- tation by the Free Software Foundation is widely available. The best course would be to incorporate the definition of the C preprocessor into the Fortran 8x draft. Despite its many shortcomings, its already widespread availability makes the C preprocessor syntax the choice for providing the include-file capability, and much more, in Fortran. Most Unix systems already allow Fortran source files to be optionally preprocessed thus. Its usefulness is somewhat limited by the restricted line-oriented Fortran-77 source format, which is another reason why Fortran 8x should decre- ment that format. The Fortran preprocessor could also be expanded to optionally provide the Fortran-66 or Fortran-77 fixed source format conversion to free form, although that function might be better left to a separate processor to encourage it to be done once and for all, rather than on every compilation. David Hough ARPA: dhough@sun.com UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough
eugene@pioneer.arpa (Eugene N. Miya) (02/21/88)
Just a short note on your comment. Years ago in grad school, I had a visiting French professor of CS who had a great little cartoon on this problem. A man (standing) (FORTRAN written across his suit) and a woman (sitting) (COBOL written over her) in a living room with a baby (PL/1) on the floor. There was a big picture window and a milkman (ALGOL written across him) with his truck walking up to the door. The husband is saying: "He doesn't look like me...." The baby and the milkman share the same face. I hope I still have this cartoon buried some place. Face it, you will never satisify users who can't (won't) change, so you might as well write a new language for new architectures. From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
henry@utzoo.uucp (Henry Spencer) (02/26/88)
> ... the C preprocessor, sometimes provided > as part of a C compiler, sometimes separately. Its defini- > tion is currently being standardized by X3J11... Beware of one fine point, though: X3J11 is *not* requiring that the preprocessor be available independently of the rest of the compiler. (They considered it but decided it was outside their jurisdiction.) -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/28/88)
In article <1988Feb25.191646.7580@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Beware of one fine point, though: X3J11 is *not* requiring that the >preprocessor be available independently of the rest of the compiler. >(They considered it but decided it was outside their jurisdiction.) More to the point, it makes sense to integrate preprocessing with other phases of lexical analysis, and there are existing C implementations that do this.
nevin1@ihlpf.ATT.COM (00704a-Liber) (03/02/88)
In article <7358@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >More to the point, it makes sense to integrate preprocessing with other >phases of lexical analysis, and there are existing C implementations >that do this. Yes, but can I get the compiler to show me the code just after going through the preprocessor? I sometimes need to see this for debugging purposes. Example (this happened yesterday): A bunch of symbols weren't being defined, but the header file containing them was in the include path. When I looked at the output of cpp, I noticed that the header file that was included was in the current directory and not the one I was expecting. Without the output of cpp it would have taken me a heck of a lot longer to find this problem. I don't care if the preprocessing is integrated with the other phases of lexical analysis, just as long as it is possible for me to get the output from the preprocessor when I need it. Will ANSI require that, or will it be implementation-dependent?? -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/03/88)
In article <3872@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >I don't care if the preprocessing is integrated with the other phases of >lexical analysis, just as long as it is possible for me to get the output >from the preprocessor when I need it. Will ANSI require that, or will it >be implementation-dependent?? It's not required by the current draft proposed standard, and I doubt that this will be changed. It is a "quality of implementation" or even "customer satisfaction" issue. You may be able to obtain a separate C preprocessor commercially or even for free (e.g. from the GNU project) that you could use during debugging.
henry@utzoo.uucp (Henry Spencer) (03/04/88)
> I don't care if the preprocessing is integrated with the other phases of > lexical analysis, just as long as it is possible for me to get the output > from the preprocessor when I need it. Will ANSI require that, or will it > be implementation-dependent?? This is clearly an implementation issue, not a language issue, and X3J11 decided not to touch it. You may, of course, wish to consider it when deciding whether to buy a particular compiler. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
Alan_T._Cote.OsbuSouth@Xerox.COM (03/04/88)
In article <7397@brl-smoke.ARPA>, Doug Gwyn <gwyn@brl-smoke.arpa> writes: >You may be able to obtain a separate C preprocessor commercially or even >for free (e.g. from the GNU project) that you could use during debugging. Isn't the free preprocessor likely to disagree with the (New! Improved :-) compiler? I would want the output from such a preprocessor to accurately reflect the interpretation the compiler would place on the code, and if the two programs don't agree about what the source code means, then the output of a separate preprocessor is next to useless!
ssd@sugar.UUCP (Scott Denham) (03/05/88)
In article <42586@sun.uucp>, dgh%dgh@Sun.COM (David Hough) writes: > The Draft should only standardize the modern free-form > source format with significant blanks, so that newly written > Fortran programs will reflect the progress in programming > language design since Algol-60. > HOGWASH!! The traditional FORTRAN 'card' image format works fine, is what thousands upon thousands of 'casual' users of the language have come to expect, and I'd be willing to bet is STILL the dominant for of FORTRAN code. I think it's fine that a 'modern' variation is allowed, or even encouraged, but to take away the old would be pointless and would ABSOLUTELY GUARANTEE the rejection of the standard. Beleive me, there are lots of FORTRAN users out there who think the standard should be frozen at '77 forever. If they wanted a 'modern' language, they'd be using one! (discussion of INCLUDE and pre-processor deleted) > The best course would be to incorporate the definition > of the C preprocessor into the Fortran 8x draft. Despite > Again I disagree. I think pre-processors are great, but let's not burden an already unwieldy standard document with another whole language, and let's not force the compiler vendors to provide one to gain certification under the 8x standard. What might be nice is to have a standalone 'standard' for a language front-end preprocessor. Remember that EVERONE will have to pay for all the bells and whistles that get tacked onto the standard. Many of us have no need for such a pre-processor or already have one that is known and loved - we don't want to pay for another one!! Tom Lahey has already estimated the effort at converting his 77 compiler to 8x at 2-3 times the difficulty of writing the original 77 from scratch! Lets not go for 4; I'm not ready for $1000 micro compilers or $2000/mo mainframe ones! > David Hough > > ARPA: dhough@sun.com > UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough Scott Denham