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
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