Re: recompile everything after compiler upgrade?

Richard Edgar <rge21@astro.su.se> writes:

> I must confess my ignorance of the detailed workings of the standards
> process, but would it be possible to add an appendix basically saying
> "We suggest you do it this way?"

Yes.  In fact, it could even be in the actual standard.  It is possible
for the standard to have recommendations (as distinct form requirements).
This has not been used much in the Fortran standard.  I'm not even sure
that it is used at all in the f95 standard (but I don't feel like
carefully examining the whle document to check).

However, I know that there is at least one case of a recommendation
in f2003.  There are probably a few others, but I distinctly recall
one, partly because I recall maaking the point that we were allowed
to do things like that.

In particular, f2003 recommends (but does not require) that the file
storage unit be an octet (aka 8-bit byte).  For those who don't
recognize the term "file storage unit" (I think it is a new term in
f2003, though not a new concept), that's the unit of measure for
record size in unformatted files.  In f2003, it pops up in several
other places, so it was worthwhile to define a term for it.

But my unsupported personal opinion is that the recommendation
proposed here would be too vague to garner much acceptance for
putting into the standard.

Note that the recommendation about the file storage unit is quite
specific, comparable to the kinds of things that the standard does
sometimes require.  It wasn't made a requirement because it might
possibly make implementation difficult on some plausible
architectures.  The requirement was a compromise that encourages
portability, but allows vendors an out if they have a defensible
reason... they would probably have to defend the reason to the users
and the standard's recommendation would provide extra "amunition" for
the users.  The file storage unit recommendation also reflects the
trend of existing implementations.

On the other hand, the recommendation dicussed in this thread stikes
me as more like some recommendations that were proposed, and even in
some interim drafts, but got pulled before the standard.  I recall
that my paraphrased summary of one of the recommendations was
"compilers should have documentation." While I certainly agree
with the sentiment, it seemed a bit silly to me to say things like
that in the standard.  There was not unanimous agreement on that
point, however.

> The whole issue seems related to the recompile cascade which afflicts
> module use

There are some things relating to recompilation cascade in 2003 (and
in particular with the modules TR, which will come out all but
similtaneously with f2003 and will likely be implemented by some
vendors even before the full f2003).

But that's a pretty big subject...and one that I could go on about
at some length (and some length for me can be pretty long), so I'll
not go into it further right now.

Some people (including the biggest proponent) even consider compilation
cascades as the primary motivation for the modules TR. I happen to
feel that it has more to do with more accurately reflecting dependencies,
and that the compilation cascade goes away as a side effect of having
the more accurate dependency model.  But elaborating on that is what
would take me a while...

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

"Richard E Maine" <nospam@see.signature> wrote in message
news:m165435evy.fsf@MLMCE0000L22801.local...
>
> Some people (including the biggest proponent) even consider compilation
> cascades as the primary motivation for the modules TR. I happen to
> feel that it has more to do with more accurately reflecting dependencies,
> and that the compilation cascade goes away as a side effect of having
> the more accurate dependency model.  But elaborating on that is what
> would take me a while...
>
But Chapter 13 and Appendix D of "Fortran 95/2003 Explained" provide just
that.

Regards,

Mike Metcalf