Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!purdue!decwrl!labrea!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <544@quintus.UUCP>
Date: 16 Oct 88 04:50:21 GMT
References: <465@quintus.UUCP> <4092@lanl.gov> <473@quintus.UUCP> <925@ccnysci.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 29

In article <925@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes:
>Unless my memory has completely gone, the C preprocessor knows nothing
>about the C language syntax.

It doesn't know about the _syntax_, but it for sure knows the _lexical_
rules!  As a particular example of why you need to take great care when
applying it to Fortran, "COS OF X" is a perfectly good Fortran identifier,
but you cannot
	#define COS OF X (something)
because identifiers may not contain spaces in C.  A worse problem is that
the C preprocessor doesn't understand Fortran continuation or comments.

>The prevailing opinion was that the preprocessor was simply a text processor...
No, the dpANS defines the action of the preprocessor in terms of TOKENS.
Tokens formed according to the lexical rules of C.

>So don't tell me that it won't do some
>fortran macro that you would like it to and conclude that it is a
>useless tool for fortran.

I don't think anyone here has said that it is _useless_ for Fortran.
The point is that because the dpANS C preprocessor is defined in terms
of *C* *tokens*, if you want to use it with a Fortran source you have
to ensure that your source follows the lexical rules of _both_ Fortran
and C, and you have to take special pains to ensure that the output
obeys the lexical rules of Fortran.  It is very easy to generate output
lines which are too long, for example.  A good way of combining C
preprocessing with Fortran is to use Ratfor (a public domain version
was posted to comp.sources.unix).