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!dhougheugene@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!eugenehenry@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