Fortran - COCO and/ior CPP users?

Author

COCO and/ior CPP users?

Joe Krahn

2005-11-09, 9:57 pm

CPP seems to be the most popular preprocessor, but is not so great at
handling FORTRAN. COCO is FORTRAN-oriented, and is an official standard,
but seems not to have too many users.

My question is: Do people dislike COCO, or are most FORTRAN users just
not interested in preprocessing?

If COCO is going to be the standard preprocessor, I think it would be
good for Fortran compilers to have built-in COCO support, invoked with
some pre-defined constants to hint about the architecture, as with C
compilers.

Joe Krahn

Rich Townsend

2005-11-10, 3:59 am

Tim Prince

2005-11-10, 3:59 am

Joe Krahn wrote:
> CPP seems to be the most popular preprocessor, but is not so great at
> handling FORTRAN.
Do you mean this in some generic sense? Do you consider gnu tradcpp and
Sun fpp to be instances of "CPP" ? Or, do you mean that current C
standard pre-processing breaks Fortran compatibility (a known fact).
gnu supports a variety of pre-processor variants. tradcpp is the one
which is compatible with "traditional" (K&R, pre-C89) usage, and is
invoked by 'g77 -E' or 'gcc -traditional -E'.
Certain Fortran compilers supply a pre-processor which combines tradcpp
style pre-processing with translation of OpenMP. This is common enough
to rival the popularity of separate cpp style pre-processors, except
that it's generally treated as part of the associated Fortran rather
than as a pre-processor with an identity.
I haven't seen a separate description of how the gfortran and gomp
projects do it; I guess it's up to us to study that.

Joe Krahn

2005-11-10, 3:59 am

Rich Townsend wrote:
> Joe Krahn wrote:
>
>
>
> I *did* use COCO, but found it far too inflexible. Essentially, it is
> for conditional compilation, not preprocessing; for instance, there is
> no support for macros.
>
> I now use fpx3 for all my preprocessing needs...
>
> cheers,
>
> Rich
The current version of COCO by Dan Nagle does have some macro support.
It looks like FPX3 will do well for me, but I suspect it is a bit too
non-FORTRANish to become 'the' standard. Maybe it is too much to expect
that a single preprocessor will become standard for Fortran.

Joe

Greg Lindahl

2005-11-10, 3:59 am

In article <BFAcf.4064$Ea3.975583@twister.southeast.rr.com>,
Joe Krahn <jkrahn@nc.rr.com> wrote:

> Maybe it is too much to expect
> that a single preprocessor will become standard for Fortran.

There already is a de-facto standard for Fortran pre-processing. It's
the K&R C pre-processor.

-- greg

robert.corbett@sun.com

2005-11-10, 3:59 am

> Do you mean this in some generic sense? Do you consider gnu tradcpp and
> Sun fpp to be instances of "CPP" ?

Note that Sun has made fpp available on netlib as open source. It can
be used
standalone, so it can be used even if the compiler you are using does
not
handle preprocessing. Some tweaks to the output routines might be
required
for some compilers.

Bob Corbett

Greg Lindahl

2005-11-10, 3:59 am

In article <WwAcf.10130$BZ5.1363@newssvr13.news.prodigy.com>,
Tim Prince <tprince@nospamcomputer.org> wrote:

> Certain Fortran compilers supply a pre-processor which combines tradcpp
> style pre-processing with translation of OpenMP. This is common enough
> to rival the popularity of separate cpp style pre-processors,

That's 2 separate things that are normally done separately but with
the same user interface, so I'd disagree that it's common; users would
happily switch to a different compiler that did the same things
implemented differently.

> I haven't seen a separate description of how the gfortran and gomp
> projects do it; I guess it's up to us to study that.

They have a preprocessor (gcc -E --traditional), and the compiler
really parses OpenMP. Which is how most compilers do it. But the user
interface is the same as using VAST; foo.F compiled with with the
"enable OpenMP" flag results in preprocessing and OpenMP.

-- greg

Rich Townsend

2005-11-10, 7:57 am

Greg Lindahl wrote:
> In article <BFAcf.4064$Ea3.975583@twister.southeast.rr.com>,
> Joe Krahn <jkrahn@nc.rr.com> wrote:
>
>
>
>
> There already is a de-facto standard for Fortran pre-processing. It's
> the K&R C pre-processor.
>
> -- greg
>
>

How is the C pre-processor at correctly wrapping expanded lines that exceed 132
characters?

Hmmm....

cheers,

Rich

David Frank

2005-11-10, 7:57 am

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:dkviuj$iua$1@scrotar.nss.udel.edu...
>
> How is the C pre-processor at correctly wrapping expanded lines that
> exceed 132 characters?
>

Also it thinks // is end of syntax instead of concatenation..

FPP that comes with CVF (and Intel) seems to be compatible with CPP but
doesnt have CPP's problems with Fortran syntax.

Greg Lindahl

2005-11-10, 7:01 pm

In article <WhIcf.7402$AS6.1108@newsread3.news.atl.earthlink.net>,
David Frank <dave_frank@hotmail.com> wrote:

>Also it thinks // is end of syntax instead of concatenation..

This is not true, Dave. The --traditional flag prevents // from being
teated specially.

-- greg

Greg Lindahl

2005-11-10, 7:01 pm

In article <dkviuj$iua$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

>How is the C pre-processor at correctly wrapping expanded lines that exceed 132
>characters?

I only said it was a de-facto standard, not that it was good at
preprocessing.

-- greg

Rich Townsend

2005-11-10, 7:01 pm

Greg Lindahl wrote:
> In article <dkviuj$iua$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
>
>
> I only said it was a de-facto standard, not that it was good at
> preprocessing.

Ah! You mean, like MS Windows is the de-facto standard operating system for x86 PCs?

:)

cheers,

Rich

Joe Krahn

2005-11-18, 3:57 am

Joe Krahn wrote:
> CPP seems to be the most popular preprocessor, but is not so great at
> handling FORTRAN. COCO is FORTRAN-oriented, and is an official standard,
> but seems not to have too many users.
>
> My question is: Do people dislike COCO, or are most FORTRAN users just
> not interested in preprocessing?
>
> If COCO is going to be the standard preprocessor, I think it would be
> good for Fortran compilers to have built-in COCO support, invoked with
> some pre-defined constants to hint about the architecture, as with C
> compilers.
>
OK, the consensus is that "cpp -traditional" still is the closest thing
to a standard preprocessor, with a few Fortran-aware CPP's called FPP,
which fix some of the issues. But, I think they still do not work well
for macros, due to line-wrapping and case sensitivity. They are mainly
good for conditional compilation.

COCO was apparently made in an attempt to do something really meant for
Fortran, rather than just an improved hack of mis-using a C/C++ tool.
The problem is that COCO is not much better than the well-established
CPP, yet it is the only preprocessor that has any standing with the
official Fortran Standards.

It seems that the closest thing to a common standard is some form of
CPP, or a slightly better version called FPP, along with OpenMP-like
directives, like !DIR$ <directive>. This latter feature is a bit like
C's #pragma directives. And, such directives can be useful, to hint at
necessary compile-time options that certain bits of code need to work
correcltly and/or efficiently. Directive can be used to give linker hints.

I thought maybe Fortran users liked COCO's idea of a Fortran-like syntax
for the preprocessor instructions. But, it seems that most people are
not interested in COCO. So, maye people would like better Fortran
preprocessor standards, but the Fortran standards groups have a hard
enough time agreeing on the languag that things like preprocessor
standards are just outside the current efforts. OR, do Fortran
programmers just not care that much about such things?

Joe

Pierre Asselin

2005-11-18, 7:01 pm

Joe Krahn <jkrahn@nc.rr.com> wrote:

> [ ... ] So, maye people would like better Fortran
> preprocessor standards, but the Fortran standards groups have a hard
> enough time agreeing on the languag that things like preprocessor
> standards are just outside the current efforts. OR, do Fortran
> programmers just not care that much about such things?

I snipped most of this informative post to keep only the end, where
I just have to respond. Speaking only for myself, I care very
much. I don't understand why Fortran still doesn't have a
preprocessor, more than two decades after the convincing proof of
concept from C. Writing portable code without a preprocessor is
such a PITA.

--
pa at panix dot com

Jan Vorbrüggen

2005-11-18, 7:01 pm

> Writing portable code without a preprocessor is such a PITA.

Given the contortions autoconfigure and make go through to produce
"portable" code, I'd say this is a kludge. You need to write in a
portable way in a portable language...as an existence proof, all
Fortran entries (AFAIK) in SPEC CFP 2000 don't use any preprocessing
and run on a wide variety of systems and compilers.

Jan

Gordon Sande

2005-11-18, 7:01 pm

On 2005-11-18 10:44:43 -0400, pa@see.signature.invalid (Pierre Asselin) said:

> Joe Krahn <jkrahn@nc.rr.com> wrote:
>
>
> I snipped most of this informative post to keep only the end, where
> I just have to respond. Speaking only for myself, I care very
> much. I don't understand why Fortran still doesn't have a
> preprocessor, more than two decades after the convincing proof of
> concept from C. Writing portable code without a preprocessor is
> such a PITA.

Having had a do-it-yourself preprocessor for some time I have observed
that ALL of my preprocessor actions involve dealing with getarg for
command line arguments. That problem will go away.

Previously there had been manifest constants under conditional compilation
to allow for vaious sized problem. That problem went away.

And so and so on.

I have seen other DIY preprocessors and they dealt with the same collection
of issues.

There used to be a problem with real vrs. double precision versions of
codes but that is history.

Fortran has reasonable capabilies for its dominant problem domains.
If you are trying to deal with either line printer vrs X11 for output
then I would expect that you need some customization tools. Such
configuration management can be kludged with a C style preprocessor
if you hold your nose. The need for C to not include duplicate headers
seems to more an example of poor design than of good configuration control.

Richard E Maine

2005-11-18, 7:01 pm

Pierre Asselin <pa@see.signature.invalid> wrote:

> Joe Krahn <jkrahn@nc.rr.com> wrote:
>
>
> Speaking only for myself, I care very
> much. I don't understand why Fortran still doesn't have a
> preprocessor...

It does have one. See the OP's first post. Now maybe you don't like the
one it has, or maybe you wonder why as many other people don't use it or
why more compilers don't ship with an implementation of it, but those
are different questions (and ones the OP was asking about). Fortran does
have a preprocessor.

I'll just contribute briefly here and then duck out. I'm afraid that one
thing you will find here is a lot of variation among users. I don't
think you are going to be able to get an answer to the question of what
Fortran users care about or like or whatever on this matter. I don't
think that qualifying it with "most Fortran users" or some such thing is
going to do it either. I think that viewpoints on this vary too widely
to make generalization at that level valid.

My own personal opinion is that the lack of a broad agreement as to what
if anything is needed is the direct cause of the lack of a broadly
accepted solution. I don't think this has much to do one way or another
with the committee or the standard. The committee did do a standard
preprocessor for Fortran, and it is used in some places, but I can't say
it is broadly accepted. You'll see lots of explanations of why it isn't
broadly accepted, but I think they mostly boil down to lack of community
consensus about what is wanted.

Oh, and my personal desires in a preprocessor? While I once wanted one,
today I really don't see much need. Mostly I can write portable code
without a preprocessor and I prefer to do it that way. In the
exceptional cases, I've usually found mechanisms other that
preprocessing to work out just as well or better for me. When I look at
where I find most use of preprocessors in C code, my usual reaction is
that it is to hack around portability problems that I just don't have in
my Fortran code.

I very much realize, though, that other people with different
perspectives do find lots of use for preprocessors with Fortran code. So
I'm not going to make any attempt to say that my preferences represent
those of "Fortran users" as a group. I think I'll stick with claiming
that the group doesn't have a widely accepted set of preferences.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Rich Townsend

2005-11-18, 7:01 pm

Richard E Maine wrote:
> Pierre Asselin <pa@see.signature.invalid> wrote:
>
>
>
>
> It does have one. See the OP's first post. Now maybe you don't like the
> one it has, or maybe you wonder why as many other people don't use it or
> why more compilers don't ship with an implementation of it, but those
> are different questions (and ones the OP was asking about). Fortran does
> have a preprocessor.
>
> I'll just contribute briefly here and then duck out. I'm afraid that one
> thing you will find here is a lot of variation among users. I don't
> think you are going to be able to get an answer to the question of what
> Fortran users care about or like or whatever on this matter. I don't
> think that qualifying it with "most Fortran users" or some such thing is
> going to do it either. I think that viewpoints on this vary too widely
> to make generalization at that level valid.
>
> My own personal opinion is that the lack of a broad agreement as to what
> if anything is needed is the direct cause of the lack of a broadly
> accepted solution. I don't think this has much to do one way or another
> with the committee or the standard. The committee did do a standard
> preprocessor for Fortran, and it is used in some places, but I can't say
> it is broadly accepted. You'll see lots of explanations of why it isn't
> broadly accepted, but I think they mostly boil down to lack of community
> consensus about what is wanted.
>
> Oh, and my personal desires in a preprocessor? While I once wanted one,
> today I really don't see much need. Mostly I can write portable code
> without a preprocessor and I prefer to do it that way. In the
> exceptional cases, I've usually found mechanisms other that
> preprocessing to work out just as well or better for me. When I look at
> where I find most use of preprocessors in C code, my usual reaction is
> that it is to hack around portability problems that I just don't have in
> my Fortran code.
>
> I very much realize, though, that other people with different
> perspectives do find lots of use for preprocessors with Fortran code. So
> I'm not going to make any attempt to say that my preferences represent
> those of "Fortran users" as a group. I think I'll stick with claiming
> that the group doesn't have a widely accepted set of preferences.
>

To add my 2 cents, I make *extensive* use of a preprocessor (fpx3 by Joerg
Behrens) -- but never for portability. I use it for generic programming; rather
than writing separate code to, e.g., reallocate rank-1 reals, integers,
logicals, characters etc, I write a single routine as a macro, and then use fpx3
to replicate it for all the types I need. All of my *portability* needs could be
wholly addressed by CoCo.

cheers,

Rich

David Ham

2005-11-18, 7:01 pm

Rich Townsend wrote:

> To add my 2 cents, I make *extensive* use of a preprocessor (fpx3 by
> Joerg Behrens) -- but never for portability. I use it for generic
> programming; rather than writing separate code to, e.g., reallocate
> rank-1 reals, integers, logicals, characters etc, I write a single
> routine as a macro, and then use fpx3 to replicate it for all the types
> I need. All of my *portability* needs could be wholly addressed by CoCo.

Ditto although we use CoCo to do generic programming. We have a sparse
matrix library supporting multiple storage schemes implimented as
different derived types. The ??text and ??copy directives are used to
throw together versions of, for example, sparse solvers for all the
different matrix types.

David

>
> cheers,
>
> Rich

Rich Townsend

2005-11-18, 7:01 pm

David Ham wrote:
> Rich Townsend wrote:
>
>
>
> Ditto although we use CoCo to do generic programming. We have a sparse
> matrix library supporting multiple storage schemes implimented as
> different derived types. The ??text and ??copy directives are used to
> throw together versions of, for example, sparse solvers for all the
> different matrix types.
>

Don't forget that ??text and ??copy are extensions to the Fortran conditional
compilation standard, that Dan Nagle implemented in his CoCo preprocessor. I
used them for a while, but eventually decided they just weren't flexible enough.

cheers,

Rich

David Ham

2005-11-18, 7:01 pm

Rich Townsend wrote:
> David Ham wrote:
>
>
> Don't forget that ??text and ??copy are extensions to the Fortran
> conditional compilation standard, that Dan Nagle implemented in his CoCo
> preprocessor. I used them for a while, but eventually decided they just
> weren't flexible enough.
>
> cheers,
>
> Rich

Oh, you are very correct. I had forgotten about that. On the other hand,
Dan's CoCo is fairly portable so it's not all that big an issue. I'll
look at fpx3, though, next time I'm starting a generic library from scratch,

David

Greg Lindahl

2005-11-18, 7:01 pm

In article <jSdff.1336$3o6.646315@twister.southeast.rr.com>,
Joe Krahn <jkrahn@nc.rr.com> wrote:

>I thought maybe Fortran users liked COCO's idea of a Fortran-like syntax
>for the preprocessor instructions. But, it seems that most people are
>not interested in COCO.

Most people don't use a preprocessor at all. The codes we run into
which want cpp -traditional tend to be huge, and so switching to a
new preprocessor would probably be expensive. Personally, I've never
ever wanted a preprocessor for code I've done -- but I've worked on
plenty of existing projects which already used cpp.

-- greg

Walter Spector

2005-11-19, 6:58 pm

Joe Krahn wrote:
> ...
> My question is: Do people dislike COCO, or are most FORTRAN users just
> not interested in preprocessing?

I think there is another possibility: Most Fortran users have never heard
of COCO, and few (if any?) vendors support it. Chicken/egg.

> If COCO is going to be the standard preprocessor, I think it would be
> good for Fortran compilers to have built-in COCO support, invoked with
> some pre-defined constants to hint about the architecture, as with C
> compilers.

It is a good observation. Send feature requests to your favorite compiler
teams. It helps if you are a paying customer.

For 'pre-defined constants', in a POSIX-compliant system, many are available
via the POSIX.9 PXF routines. Depending on which ones one is interested in,
the PXFCONST (and friends), PXFSYSCONF, and/or PXFPATHCONF routines may be useful.
In a good implementation of PXF, several hundred values are available for all
sorts of uses.

Unfortunately, the PXF stuff is also somewhat hit or miss. There are a number
of commercial implementations that support PXF and a number that pretend it
doesn't exist. If I were a paying customer of a compiler that did not
support PXF, I'd certainly be pestering said vendor for it. (And am also
amazed that the g77/g95/gfortran guys still have not implemented it...)

Walt

glen herrmannsfeldt

2005-11-19, 6:59 pm

Pierre Asselin wrote:

(snip)

> I snipped most of this informative post to keep only the end, where
> I just have to respond. Speaking only for myself, I care very
> much. I don't understand why Fortran still doesn't have a
> preprocessor, more than two decades after the convincing proof of
> concept from C. Writing portable code without a preprocessor is
> such a PITA.

I have in the past (maybe not here) commented on the trend from PL/I to
C to Java, with ever decreasing power in the preprocessor. The only
thing Java gives you is the requirement that the code inside an

if(false)

block won't be compiled. (One of the popular uses for the C
preprocessor is conditional compilation, but C makes no requirements on
the code inside an

#if 0
#endif

block, except possibly to matching comments. As C comments don't nest,
#if 0 is often used to "comment out" a large block of code.

While conditional compilation is often used for portability, is is also
useful for describing different versions of the same code. Debugging
code can be conditionally compiled. For programs with a trial and full
version, one can conditionally compile the code in the trial version.

It is much easier to keep versions consistent when the come from the
same code. Attempting to keep separate files in sync as far as common
changes is almost impossible.

-- glen

Pierre Asselin

2005-11-22, 7:01 pm

Jan Vorbr?ggen <jvorbrueggen-not@mediasec.de> wrote:
[color=darkred]
> Given the contortions autoconfigure and make go through to produce
> "portable" code, I'd say this is a kludge. You need to write in a
> portable way in a portable language...as an existence proof, all
> Fortran entries (AFAIK) in SPEC CFP 2000 don't use any preprocessing
> and run on a wide variety of systems and compilers.

It depends what you're trying to do. For example, how do you
* overprint an output line
* output a partial line
* flush I/O buffers
* cd to another directory
* create a directory
* get to the command line
* manipulate the IEEE flags

This is just a quick list, some of which come from googling recent
posts in this newsgroup. Many items are covered by F2003, some
items are covered by auxiliary standards that are not widely
deployed, but pretty darn every one of them can be done with
vendor-specific extensions. It is at this point that a preprocessor
becomes useful. Not indispensable, but it really is a PITA not to
have one.

--
pa at panix dot com

Pierre Asselin

2005-11-22, 7:01 pm

Richard E Maine <nospam@see.signature> wrote:
> Pierre Asselin <pa@see.signature.invalid> wrote:

[color=darkred]
> It does have one. See the OP's first post. Now maybe you don't like the
> one it has, [ ... ]

Actually no, I checked it out and it's quite okay. I just wasn't
aware of it.

> or maybe you wonder why as many other people don't use it or
> why more compilers don't ship with an implementation of it,

the latter

> but those
> are different questions (and ones the OP was asking about). Fortran does
> have a preprocessor.

Agreed. Like I said, I wasn't even aware that COCO had any kind of
standard status. It seems to be one of those auxiliary standards
that aren't widely deployed :-( Thanks to Dan for the implementation.

I can install COCO on all my boxes. I can use it on *nix, no problem.
On Windows, I have to squeeze it past the damned Wizard. There has
to be a way. Actually, I don't know that... it's so much harder
to do anything on Windows not bundled by the vendor. Bah.

> I'll just contribute briefly here and then duck out. [ ... ]

That was informative. Thank you.

--
pa at panix dot com

Sponsored Links