From: Richard Maine on
Paul van Delst <paul.vandelst(a)noaa.gov> wrote:

> And I'm a little bit afraid to even put forward my opinion. I don't want
> to make DanN mad at me! (Just kidding Dan! :o)

Dan's decent about that kind of thing. I disagree with him rather
strongly on this matter. (As I said, I'm not continuing the argument -
just dropped it while still disagreeing). But I'm quite confident that
If I run into him in person again, which could reasonably well happen,
we'll sit down to a quite friendly chat over dinner or whatever. We have
before.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Bil Kleb on
Paul van Delst wrote:
> The code that we distribute is run on all sorts of machines (mostly *nix)
> with various flavours of compilers from different vendors.

So do we. We try to accommodate this with hand rolled M4 macros
for autoconf and our gantlet of compilers. How do you approach it?

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
From: nmm1 on
In article <hble5g$ibi$1(a)news.eternal-september.org>,
Bil Kleb <Bil.Kleb(a)nasa.gov> wrote:
>Paul van Delst wrote:
>> The code that we distribute is run on all sorts of machines (mostly *nix)
>> with various flavours of compilers from different vendors.
>
>So do we. We try to accommodate this with hand rolled M4 macros
>for autoconf and our gantlet of compilers. How do you approach it?

autoconf is catastrophic for extreme portability, whether between
systems or across time, as it means a redesign every time you need
to port to a very different system. In one actual case (NTP, not
in Fortran), it was quicker for me to design, write and debug a very
high-quality SNTP program than EITHER of the following:

To port autoconf (and all that it relied on)

To reverse engineer even the essentials of xntp's autoconf

I never even estimated the actual porting effort! It would have
been MUCH easier if autoconf had allowed cross-configuration, but
it didn't (and I believe still doesn't).

I had a similar experience a decade earlier with the X Windowing
System, where it was many times as much work to port the automatic
configuration system as to port the code. Several weeks of it ....

I agree that, in extreme cases, the choice is between using preprocessor
spaghetti and a zillion variant auxiliary functions. My objections
are mainly to the abomination that is autoconf.

The way that I do it is to write to an acceptable minimal subset,
and use preprocessing and variant code only in extremis - with care
and suitable experience, it is surprising how rarely it is needed in
Fortran. But I am not denying that it IS needed.

There is currently a proposal to SC22WG5 to define a 'cleaned-up'
subset of portable, reliable Fortran. At least two national bodies
are very interested. The ground rules would be that it would be a
STRICT subset, and any changes found to be needed would have to be
made in the full language (or rejected).


Regards,
Nick Maclaren.
From: robin on
"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:hbi7qq$g2s$5(a)naig.caltech.edu...
| David Muxworthy <d.muxworthy(a)bcs.org.uk> wrote:

| > The prime reason for having a standard is, as the document itself
| > says, 'to promote portability, reliability, maintainability, and
| > efficient execution of Fortran programs for use on a variety of
| > computing systems', including different compilers on a single
| > installation. Now we have the situation that vendors are giving
| > low priority to some features in f03 while already implementing
| > some features from f08, so that for some years potentially every
| > vendor will have its own subset of f08. What value is that for
| > people wanting to write portable programs? Delaying f08 would
| > make time for more uniform implementations across vendors.
|
| It would seem not much help to those wanting portable programs
| using all the features, but maybe for specific features.

A bit difficult when there are no full implementations of F03 on the PC.