experchange > fortran

Beliavsky (01-28-19, 06:07 PM)
The C++ committee may add modules to the language, and some people are warning that Fortran's approach to modules should be avoided because it often requires many source files to be recompiled:

C++ Modules Might Be Dead-on-Arrival
Jan 27, 2019

(discussed at )

refers to the paper

Remember the FORTRAN


Since I'm a Fortran 95 dinosaur I don't know if the submodules of Fortran 2008 and extended Fortran 2003 have solved the problem.

It's nice that more modern versions of Fortran are being held up as examples what not to do, after decades of FORTRAN IV and FORTRAN 77 playing that role :).
FortranFan (01-28-19, 07:15 PM)
On Monday, January 28, 2019 at 11:07:56 AM UTC-5, Beliavsky wrote:
> The C++ committee may add modules to the language, and some people are warning that Fortran's approach to modules should be avoided because it oftenrequires many source files to be recompiled:
> C++ Modules Might Be Dead-on-Arrival
> Jan 27, 2019
>
> (discussed at )
> refers to the paper
> Remember the FORTRAN
>
> Since I'm a Fortran 95 dinosaur I don't know if the submodules of Fortran2008 and extended Fortran 2003 have solved the problem.
> It's nice that more modern versions of Fortran are being held up as examples what not to do, after decades of FORTRAN IV and FORTRAN 77 playing thatrole :).


It was pointed out on this forum back in 2016 June the new feature under consideration in C++ resembles that in Fortran (and other languages prior):


Re: ".. I don't know if the submodules of Fortran 2008 and extended Fortran2003 have solved the problem," well, the problem as stated by the opponents of modules in C++ involve the build system and the extra dependency that comes into play. And these opponents appear particularly concerned with scale i.e., with large C++ projects. Fortran 2008 with SUBMODULEs has in no way "solved the problem". If anything, an added layer of dependency has come in with SUBMODULEs and compilers such as Intel Fortran has faced difficulties and run into compiler regressions in trying to get SUBMODULEs right including with their recent revisions. Regardless, I will maintain MODULEs and SUBMODULEs are really VALUABLE, INDISPENSABLE even, to Fortran and I think they can be to C++ also. Yes, there are "issues" one will face with the build system while using MODULEs and SUBMODULEs but these problems can beaddressed and resolved over time in other ways. No need to throw the "baby" out with the bath water.

In the case of Intel Fortran on Windows and Visual Studio and with small tomedium-size projects involving a couple to hundreds of source files spreadacross say multiple subprojects, the dependency aspect that is of concern to opponents of said feature in C++ is quite manageable now. The "build system" of Intel Fortran integration with Visual Studio does help coders tackle most issues. What I don't know is how well this scales to massive projects.
Ron Shepard (01-28-19, 09:55 PM)
On 1/28/19 10:07 AM, Beliavsky wrote:
[...]

> Remember the FORTRAN
>


On the second page of this document is the sentence

"If you edit the code by changing the contents of files B and C (but not
changing them in any way) then the order changes to B => C => A."

What exactly does that sentence mean? How do you change the contents of
things without changing them in any way?

On this topic in general, I think this is an issue that could be
addressed better by both the language standard and by compiler vendors.
Suppose, for example, you have the C=>B=>A dependency discussed in that
paragraph, and suppose further that you have conditional compilation in
the B and C files (e.g. B.F90 and C.F90). It might occur that with one
set of compiler options the dependency is B=>C and with another set of
compiler options the dependency is C=>B. One could not write a static
makefile that accounted for that dynamic change of dependency. Somehow
the source files would need to be scanned, with full knowledge of the
compiler options and of the conditional compilation, to establish the
correct compilation order.

Is that the situation that the C++ people are complaining about in
fortran? If so, then that seems rather obscure. Yes, one can imagine
doing that, but it isn't something that happens often in practice. It is
sort of like the problem of having a cyclical dependence between two
files, it is something that the programmer needs to avoid.

Also, that article does not mention what is the real practical problem
with the fortran module system. Namely, the file dependencies are such
that making trivial changes (e.g. in a comment line) can invoke a
compilation cascade when it is not needed. This is also a dynamical
problem, where the ultimate solution is to compile the changed file,
then examine the *.mod files that are created to see if any further
compilations in the dependency chain are required. If this issue is
addressed by the language standard, it would require some kind of
standardization of the module files themselves, something that has not
been done to date.

On the general idea of creating dependencies automatically, I have
always been skeptical of this. It is common, for example, to have
several versions of a particular file in a directory but to use only one
of them at a time. The files might have machine dependencies within, so
that you want one version on one computer and another version on another
computer. You see this a lot with fortran codes because fortran doesn't
really have a standard preprocessor built into the language (which to me
is the right way to handle these kinds of dependencies). That should
have been done back with f77, but it wasn't, so here we are 40 years
later, still suffering from that decision. Anyway, given that there are
several possible files available to create the same .mod file, it is not
possible, even in principle, to automatically scan them to create the
correct dependency list.

What kinds of tools could be built to help with this task. I look at it
as a way to automatically build a Makefile, although I know that there
are other build tools in use to accomplish this task. Take a step back
and ask the question, would it help programmers if there were tools that
verified the dependencies that are specified in a given Makefile? That
seems to be a simpler task. That tool would need to recognize when
stated dependencies were not valid, when stated dependencies are
reversed, when dependencies exist in the code that are not stated, and
when stated dependencies are cyclic.

Something else that would be useful is for the compiler to tell you when
a USE statement is unnecessary. There are several ways this can occur.
It could already be USED indirectly through another USE statement, or it
could be USED at the module level or the containing host level, or
nothing that it brings into scope could be referenced.

For a large programming project, the current situation is that
maintaining the Makefile (or sometimes several of them) is just as
critical as maintaining the fortran source itself. Make is an imperfect
tool, quirky, even difficult to understand at times, but it seems to be
the most portable thing available.

$.02 -Ron Shepard
Spiros Bousbouras (01-28-19, 10:03 PM)
On Mon, 28 Jan 2019 13:55:03 -0600
Ron Shepard <nospam> wrote:
> On 1/28/19 10:07 AM, Beliavsky wrote:
> [...]
> On the second page of this document is the sentence
> "If you edit the code by changing the contents of files B and C (but not
> changing them in any way) then the order changes to B => C => A."
> What exactly does that sentence mean? How do you change the contents of
> things without changing them in any way?


I think it means swapping the contents i.e. what was in file B goes in file
C and vice versa.
Thomas Koenig (01-28-19, 10:56 PM)
Beliavsky <beliavsky> schrieb:
> The C++ committee may add modules to the language, and some people are warning that Fortran's approach to modules should be avoided because it often requires many source files to be recompiled:
> C++ Modules Might Be Dead-on-Arrival
> Jan 27, 2019
>
> (discussed at )


If you watch , you will come
to the realization that C++ mdoules, as planned, are indeed a horrible
idea. These guys managed to add quite a few strange concepts to what
Fortran has. You will also note a few critical questions from Fortran
people in the audience :-)
spectrum (01-28-19, 11:06 PM)
> (discussed at )

I guess the above URL is a typo of this page (in HackerNews):


# And, interestingly, "WalterBright" is writing several comments
to advertise modules in his language :-D
Lynn McGuire (01-29-19, 08:36 PM)
On 1/28/2019 10:07 AM, Beliavsky wrote:
> The C++ committee may add modules to the language, and some people are warning that Fortran's approach to modules should be avoided because it often requires many source files to be recompiled:
> C++ Modules Might Be Dead-on-Arrival
> Jan 27, 2019
>
> (discussed at )
> refers to the paper
> Remember the FORTRAN
>
> Since I'm a Fortran 95 dinosaur I don't know if the submodules of Fortran 2008 and extended Fortran 2003 have solved the problem.
> It's nice that more modern versions of Fortran are being held up as examples what not to do, after decades of FORTRAN IV and FORTRAN 77 playing that role :).


Sorry, I did not see that you posted this already !

Lynn
FortranFan (01-29-19, 09:43 PM)
On Monday, January 28, 2019 at 12:15:43 PM UTC-5, FortranFan wrote:

> .. the problem as stated by the opponents of modules in C++ involve the build system and the extra dependency that comes into play. And these opponents appear particularly concerned with scale i.e., with large C++ projects.. ..


If these opponents of modules in C++ hold sway, it's possible C++ introduces further syntax and idioms toward module programming in order to move awayfrom these concerns with build dependencies and so forth! Or C++ might choose to use or extend the already esoteric stuff with their template metaprogramming toward modules to further complicate that language! It'll be interesting to see the path taken by C++.