I've been translating some Runge-Kutta vibration analysis code from C
to Fortran 2003/08. Finally, I got it up and running - all was fine.
The C code and Fortran code were producing nearly identical numbers.
Then, while perusing the software "add/remove package" utility on
Fedora 16, searching under gfortran, I noticed and added
"Compatibility Fortran 95 runtime library version 4.1.2" and "Static
Fortran libraries". After I rebooted, the Fortran code I wrote (that
I was running), wouldn't compile:
$ gfortran plates.f95
plates.f95:91.12:
use geometry
1
Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
No such file or directory
My client had insisted that all the code be in 1 file. So I placed
all 8 modules + program (main) in 1 file ... not worrying about the
order of the modules in the file. I had wondered about the module
order but since it compiled I assume - no problem: the order of the
modules in the file didn't matter.
Now, because of this compile time error, I moved "module geometry" up
front and all is fine ... again.
On Tuesday, September 18, 2012 3:23:30 PM UTC+2, jski wrote:
> I've been translating some Runge-Kutta vibration analysis code from C
> to Fortran 2003/08. Finally, I got it up and running - all was fine.
> The C code and Fortran code were producing nearly identical numbers.
> Then, while perusing the software "add/remove package" utility on
> Fedora 16, searching under gfortran, I noticed and added
> "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
> Fortran libraries". After I rebooted, the Fortran code I wrote (that
> I was running), wouldn't compile:
> $ gfortran plates.f95
> plates.f95:91.12:
> use geometry
> 1
> Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
> No such file or directory
> My client had insisted that all the code be in 1 file. So I placed
> all 8 modules + program (main) in 1 file ... not worrying about the
> order of the modules in the file. I had wondered about the module
> order but since it compiled I assume - no problem: the order of the
> modules in the file didn't matter.
> Now, because of this compile time error, I moved "module geometry" up
> front and all is fine ... again.
> Go figure?
> ---John
The information that a compiler needs about a module is usually stored in
an external file (geometry.mod or something similar). These files are created
as the compiler processes the file. If the module is USED, before its declaration occurs, then an existing version of this intermediate file may
be used by the compiler instead. Which might be out-of-date.
So, in general, if your source files contain more than one module, make
sure they physically appear before they are used. If you have more than
one source file, make sure the files are compiled in the right order.
> On Tuesday, September 18, 2012 3:23:30 PM UTC+2, jski wrote:
> > I've been translating some Runge-Kutta vibration analysis code from C
> > to Fortran 2003/08. Finally, I got it up and running - all was fine.
> > The C code and Fortran code were producing nearly identical numbers.
> > Then, while perusing the software "add/remove package" utility on
> > Fedora 16, searching under gfortran, I noticed and added
> > "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
> > Fortran libraries". After I rebooted, the Fortran code I wrote (that
> > I was running), wouldn't compile:
> > $ gfortran plates.f95
> > plates.f95:91.12:
> > use geometry
> > 1
> > Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
> > No such file or directory
> > My client had insisted that all the code be in 1 file. So I placed
> > all 8 modules + program (main) in 1 file ... not worrying about the
> > order of the modules in the file. I had wondered about the module
> > order but since it compiled I assume - no problem: the order of the
> > modules in the file didn't matter.
> > Now, because of this compile time error, I moved "module geometry" up
> > front and all is fine ... again.
> > Go figure?
> > ---John
> The information that a compiler needs about a module is usually stored in
> an external file (geometry.mod or something similar). These files are created
> as the compiler processes the file. If the module is USED, before its
> declaration occurs, then an existing version of this intermediate file may
> be used by the compiler instead. Which might be out-of-date.
> So, in general, if your source files contain more than one module, make
> sure they physically appear before they are used. If you have more than
> one source file, make sure the files are compiled in the right order.
> Regards,
> Arjen
But in this case (by customer request) all the source was in 1 file.
---John
> I've been translating some Runge-Kutta vibration analysis code from C
> to Fortran 2003/08. Finally, I got it up and running - all was fine.
> The C code and Fortran code were producing nearly identical numbers.
> Then, while perusing the software "add/remove package" utility on
> Fedora 16, searching under gfortran, I noticed and added
> "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
> Fortran libraries". After I rebooted, the Fortran code I wrote (that
> I was running), wouldn't compile:
> $ gfortran plates.f95
> plates.f95:91.12:
> use geometry
> 1
> Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
> No such file or directory
> My client had insisted that all the code be in 1 file. So I placed
> all 8 modules + program (main) in 1 file ... not worrying about the
> order of the modules in the file. I had wondered about the module
> order but since it compiled I assume - no problem: the order of the
> modules in the file didn't matter.
> Now, because of this compile time error, I moved "module geometry" up
> front and all is fine ... again.
> Go figure?
> ---John
The generated module files (usually with the extension .mod) resemble the header files of C/C++. They hold similar information. But there are important differences:
1) They are generated by the compiler, not by the programmer.
2) The order of compilation does matter, because modules depend on other modules.
3) The file format is non-portable between compilers. In particular, it is often non-portable between different versions of the same compiler.
Nothing of this is mentioned in the standard. The standard does not even mention the existence of module files, IIRC.
Likewise, it doesn't matter how you distribute modules among source files. The concept of a source file is not a matter of the standard, either. It is the dependency tree of modules which is important.
If you don't have old gfortran-compiled binaries and module files, there is no need to install gfortran-4.1 runtime libraries. That was an old compiler version, current is 4.6/7/8.
> > I've been translating some Runge-Kutta vibration analysis code from C
> > to Fortran 2003/08. Finally, I got it up and running - all was fine.
> > The C code and Fortran code were producing nearly identical numbers.
> > Then, while perusing the software "add/remove package" utility on
> > Fedora 16, searching under gfortran, I noticed and added
> > "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
> > Fortran libraries". After I rebooted, the Fortran code I wrote (that
> > I was running), wouldn't compile:
> > $ gfortran plates.f95
> > plates.f95:91.12:
> > use geometry
> > 1
> > Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
> > No such file or directory
> > My client had insisted that all the code be in 1 file. So I placed
> > all 8 modules + program (main) in 1 file ... not worrying about the
> > order of the modules in the file. I had wondered about the module
> > order but since it compiled I assume - no problem: the order of the
> > modules in the file didn't matter.
> > Now, because of this compile time error, I moved "module geometry" up
> > front and all is fine ... again.
> > Go figure?
> > ---John
> The generated module files (usually with the extension .mod) resemble
> the header files of C/C++. They hold similar information. But there
> are important differences:
> 1) They are generated by the compiler, not by the programmer.
> 2) The order of compilation does matter, because modules depend on other
> modules.
> 3) The file format is non-portable between compilers. In particular, it
> is often non-portable between different versions of the same compiler.
> Nothing of this is mentioned in the standard. The standard does not
> even mention the existence of module files, IIRC.
> Likewise, it doesn't matter how you distribute modules among source
> files. The concept of a source file is not a matter of the standard,
> either. It is the dependency tree of modules which is important.
> If you don't have old gfortran-compiled binaries and module files, there
> is no need to install gfortran-4.1 runtime libraries. That was an old
> compiler version, current is 4.6/7/8.
> I've been translating some Runge-Kutta vibration analysis code from C
> to Fortran 2003/08. Finally, I got it up and running - all was fine.
> The C code and Fortran code were producing nearly identical numbers.
> Then, while perusing the software "add/remove package" utility on
> Fedora 16, searching under gfortran, I noticed and added
> "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
> Fortran libraries". After I rebooted, the Fortran code I wrote (that
> I was running), wouldn't compile:
> $ gfortran plates.f95
> plates.f95:91.12:
> use geometry
> 1
> Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
> No such file or directory
> My client had insisted that all the code be in 1 file. So I placed
> all 8 modules + program (main) in 1 file ... not worrying about the
> order of the modules in the file. I had wondered about the module
> order but since it compiled I assume - no problem: the order of the
> modules in the file didn't matter.
> Now, because of this compile time error, I moved "module geometry" up
> front and all is fine ... again.
> Go figure?
> ---John
Compile it TWICE!
For one compile the order of the modules matters. Declare it before using it.
But if you forget to delete the .mod files then the declaration from the
first compile will be there as a .mod file for the use in the second compile.
If you are a tidy sort and delete all the .mod files at the end then the two
compile scheme will not work.
> I was just exploring and playing with gfortran (I'm a newbie BUT very
> impressed with Fortran vs. C for numerical coding).
> But what about the order of the modules, if all the code is in 1 file?
The compiler is likely (but, strictly speaking, not require to) compile the modules in the order that they have been written in the file. If the file looks like
module a
...
end module a
module b
use module a
...
end module b
everything is probably fine, because a.mod will be available in time for the compilation of b. But if the file looks like
module b
use module a
...
end module b
module a
...
end module a
a.mod will either not be available or, even worse, the compiler may read a file a.mod that was left over from a previous compilation. This may result in anything from everything ok, strange warnings, errors, to apparently successful compilation with wrong results (the worst case).
> > I've been translating some Runge-Kutta vibration analysis code from C
> > to Fortran 2003/08. Finally, I got it up and running - all was fine.
> > The C code and Fortran code were producing nearly identical numbers.
> > Then, while perusing the software "add/remove package" utility on
> > Fedora 16, searching under gfortran, I noticed and added
> > "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
> > Fortran libraries". After I rebooted, the Fortran code I wrote (that
> > I was running), wouldn't compile:
> > $ gfortran plates.f95
> > plates.f95:91.12:
> > use geometry
> > 1
> > Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
> > No such file or directory
> > My client had insisted that all the code be in 1 file. So I placed
> > all 8 modules + program (main) in 1 file ... not worrying about the
> > order of the modules in the file. I had wondered about the module
> > order but since it compiled I assume - no problem: the order of the
> > modules in the file didn't matter.
> > Now, because of this compile time error, I moved "module geometry" up
> > front and all is fine ... again.
> > Go figure?
> > ---John
> Compile it TWICE!
> For one compile the order of the modules matters. Declare it before using it.
> But if you forget to delete the .mod files then the declaration from the
> first compile will be there as a .mod file for the use in the second compile.
> If you are a tidy sort and delete all the .mod files at the end then the two
> compile scheme will not work.
That brings up an interesting question: assume geometry.mod exited so
the compiler could find the required *.mod file but the modules are
misordered. So the compiler doesn't recognize the misorder and
continues compiling. Then I modify the code within geometry, so the
compiler sees geometry.mod and proceeds to compile. When it gets to
the modified code in geometry it builds a new geometry.mod file and
all in seemingly fine?
> On Sep 18, 10:14 am, Gordon Sande<Gordon.Sa...@gmail.com> wrote:
> That brings up an interesting question: assume geometry.mod exited so
> the compiler could find the required *.mod file but the modules are
> misordered. So the compiler doesn't recognize the misorder and
> continues compiling. Then I modify the code within geometry, so the
> compiler sees geometry.mod and proceeds to compile. When it gets to
> the modified code in geometry it builds a new geometry.mod file and
> all in seemingly fine?
Don't count on that. Simply get the order right. If uncertain, delete all .mod files and then compile once.
> But in this case (by customer request) all the source was in 1 file.
Must have had a previous version of the module for it to have found, then. Having previously compiled the file containing the module before adding a USE statement could have done that or having first had the module in another file before placing it in the one...
Any number of ways but the source for the module will have had to have been compiled prior to the first USE of the module or the "not found" message will happen.
> On Sep 18, 10:14 am, Gordon Sande <Gordon.Sa...@gmail.com> wrote:
>> On 2012-09-18 10:23:30 -0300, jski said:
>>> I've been translating some Runge-Kutta vibration analysis code from C
>>> to Fortran 2003/08. Finally, I got it up and running - all was fine.
>>> The C code and Fortran code were producing nearly identical numbers.
>>> Then, while perusing the software "add/remove package" utility on
>>> Fedora 16, searching under gfortran, I noticed and added
>>> "Compatibility Fortran 95 runtime library version 4.1.2" and "Static
>>> Fortran libraries". After I rebooted, the Fortran code I wrote (that
>>> I was running), wouldn't compile:
>>> $ gfortran plates.f95
>>> plates.f95:91.12:
>>> use geometry
>>> 1
>>> Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
>>> No such file or directory
>>> My client had insisted that all the code be in 1 file. So I placed
>>> all 8 modules + program (main) in 1 file ... not worrying about the
>>> order of the modules in the file. I had wondered about the module
>>> order but since it compiled I assume - no problem: the order of the
>>> modules in the file didn't matter.
>>> Now, because of this compile time error, I moved "module geometry" up
>>> front and all is fine ... again.
>>> Go figure?
>>> ---John
>> Compile it TWICE!
>> For one compile the order of the modules matters. Declare it before using it.
>> But if you forget to delete the .mod files then the declaration from the
>> first compile will be there as a .mod file for the use in the second compile.
>> If you are a tidy sort and delete all the .mod files at the end then the two
>> compile scheme will not work.
> That brings up an interesting question: assume geometry.mod exited so
> the compiler could find the required *.mod file but the modules are
> misordered. So the compiler doesn't recognize the misorder and
> continues compiling. Then I modify the code within geometry, so the
> compiler sees geometry.mod and proceeds to compile. When it gets to
> the modified code in geometry it builds a new geometry.mod file and
> all in seemingly fine?
> ---John
The compile it twice is a hack to compensate for a dumb/lazy programmer.
The two compiles need to be one after the other with the same source
and assume that there is no deeper dependency. That might need more compiles!
If you change the code and there is an old .mod floating around you deserve
whatever happens as a result of your laziness. You will get no sympathy from me.
I would believe you have not figured out the purpose of the .mod files if
you are thinking of playing such tricks. If you claim you are just playing devil's
advocate then you have been a very slow learner.
The sensible policy is to always clean out the .mod files. If you are shipping
object then you will have the problem of shipping matching object and .mod files.
Perhaps you client who wants a clean single file compile knows something that you have
not quite groacked yet.
Wolfgang Kilian <see...@domain.invalid> wrote:
> 2) The order of compilation does matter, because modules depend on other
> modules.
...
> Nothing of this is mentioned in the standard. The standard does not > even mention the existence of module files, IIRC.
That part about the order of compilation mattering is alluded to in the
standard in vague terms. It doesn't say anything so clear as "order of
compilation". Heck, the standard doesn't even define a concept of
compilation in so many words.
It does say , in 11.2.1 of f2003,
"At the time a USE statement is processed, the public portions of the
specified module shall be available."
Read "processed" as roughly standard-speak for "compiled" (with emphasis
on the "roughly"). Exactly what it means for the public portions to be
"available" is not defined by the standard. But that's at least a hint
that something relating to the used module has to exist when compiling
the USE statement. There has been at least one implementation (a
horribly poorly done one for many reasons) where that just meant that
the source code for the used module was directly accessed when compiling
the USE statement. Most often, it means what you describe, that the
module is "available" when the .mod file has been created (and is in the
seach path for such files).
-- Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
> On 09/18/2012 04:41 PM, jski wrote:
>> On Sep 18, 10:14 am, Gordon Sande<Gordon.Sa...@gmail.com> wrote:
>> That brings up an interesting question: assume geometry.mod exited so
>> the compiler could find the required *.mod file but the modules are
>> misordered. So the compiler doesn't recognize the misorder and
>> continues compiling. Then I modify the code within geometry, so the
>> compiler sees geometry.mod and proceeds to compile. When it gets to
>> the modified code in geometry it builds a new geometry.mod file and
>> all in seemingly fine?
> Don't count on that. Simply get the order right. If uncertain, delete
> all .mod files and then compile once.
If the compiler can't recognize the module source has been modified, then if the USE is before the source in the compilation order it will have an outdated .mod file to USE...whether there's anything that's changed in the source that matters will depend entirely on what those changes are--if you modified an interface then it may matter a lot.
Fix the compilation order correctly; do _not_ let something like this go--it's rife w/ hard-to-diagnose possible problems.
dpb <n...@non.net> wrote:
> Fix the compilation order correctly; do _not_ let something like this
> go--it's rife w/ hard-to-diagnose possible problems.
Heck. It is asking for problems of a type I have seen plenty of times:
the programmer can't figure out why the code he is studying gives the
results that he sees... because the code he is looking at isn't actually
what ran to get those results. That can happen all kinds of ways. One of
the easiest variants is to edit the code, but fail to recompile it, so
that you are running a different version of the code than you are
looking at. There are other ways to have the same kind of error.
Another variant I have seen is to finally get a debugged and tested
version of your program, but then package up and send out the wrong
version of the source. That can make for puzzlement when the person you
send it to gets different results than you did.
Just assuming that recompiling the code multiple times will work
provides yet another path to that kind of error.
-- Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
> The sensible policy is to always clean out the .mod files. If you are
> shipping object then you will have the problem of shipping matching
> object and .mod files. Perhaps you client who wants a clean single
> file compile knows something that you have not quite groacked yet.
You know, I would "blame" the client for this sort of dilemma.
Tools exist (e.g. makefile) that allow for dependencies to be checked automatically if anything is modified. By specifying that all the code has to be in one file the efficacy of those tools is curtailed ... which suggests to me the client is, uh, not as knowledable as he/she should be.
I mean, why should they care how the delivered code is organised as long as:
1) It is easy breezy to build the executable, and
2) The results are correct.
> On 09/18/12 12:52, Gordon Sande wrote:
>> The sensible policy is to always clean out the .mod files. If you are
>> shipping object then you will have the problem of shipping matching
>> object and .mod files. Perhaps you client who wants a clean single
>> file compile knows something that you have not quite groacked yet.
> You know, I would "blame" the client for this sort of dilemma.
> Tools exist (e.g. makefile) that allow for dependencies to be checked > automatically if anything is modified. By specifying that all the code > has to be in one file the efficacy of those tools is curtailed ... > which suggests to me the client is, uh, not as knowledable as he/she > should be.
> I mean, why should they care how the delivered code is organised as long as:
> 1) It is easy breezy to build the executable, and
One man's "easy breezy" is another's "how in the hell do you do that?" The
assumption that the client is running a full extensive set of software engineering
tools is a very pleasant but not very realistic dream. It may be that the client
can not get things past the local system administrator/purchasing crowd and having
a single file is the only "easy breezy" way that has been found to work. Been
awfully close to that and heard repetitions of the story too often!
The extreme case I once visited and heard war stories from was a drug company that
had to keep one machine "clean" for the analysis of trials for submitting to the
drug regulation agency. Rather sharp folks who knew both how to do things and how
to get their products through the approval process. Somehow I would not apply
"not as knowledable as he/she should be" to that group. Not all shoes are equally
confortable for walking.
> 2) The results are correct.
> ?
> Why constrain the developer?
Who claims to be professional and is taking money for their effort? Some things
should be very tight and others quite loose. If they only speak German they can
probably find a good German translator with experince in the field much quicker
than I could to give an instance where I would be fussy on a side issue. But I
would expect them to have considerable freedom on at least some aspects of the
content.
Richard Maine <nos...@see.signature> wrote:
> Wolfgang Kilian <see...@domain.invalid> wrote:
>> 2) The order of compilation does matter, because modules depend on other
>> modules.
> ...
>> Nothing of this is mentioned in the standard. The standard does not >> even mention the existence of module files, IIRC.
> That part about the order of compilation mattering is alluded to in the
> standard in vague terms. It doesn't say anything so clear as "order of
> compilation". Heck, the standard doesn't even define a concept of
> compilation in so many words.
> It does say , in 11.2.1 of f2003,
> "At the time a USE statement is processed, the public portions of the
> specified module shall be available."
> Read "processed" as roughly standard-speak for "compiled" (with emphasis
> on the "roughly"). Exactly what it means for the public portions to be
> "available" is not defined by the standard. But that's at least a hint
> that something relating to the used module has to exist when compiling
> the USE statement.
So a compiler might not write the MOD file (or however it got the
data to subsequent USE) right away at the end of the module?
Possibly not until EOF on the input source file?
In that case, it might not be possible to compile a single file containing modules and module users.
In any case, within the same file MODULEs should come before USErs
of each module.
On Tue, 18 Sep 2012 23:03:39 +0000, glen herrmannsfeldt wrote:
> Richard Maine <nos...@see.signature> wrote:
>> Wolfgang Kilian <see...@domain.invalid> wrote:
>>> 2) The order of compilation does matter, because modules depend on other
>>> modules.
>> ...
>>> Nothing of this is mentioned in the standard. The standard does not >>> even mention the existence of module files, IIRC.
>> That part about the order of compilation mattering is alluded to in the
>> standard in vague terms. It doesn't say anything so clear as "order of
>> compilation". Heck, the standard doesn't even define a concept of
>> compilation in so many words.
>> It does say , in 11.2.1 of f2003,
>> "At the time a USE statement is processed, the public portions of the
>> specified module shall be available."
>> Read "processed" as roughly standard-speak for "compiled" (with emphasis
>> on the "roughly"). Exactly what it means for the public portions to be
>> "available" is not defined by the standard. But that's at least a hint
>> that something relating to the used module has to exist when compiling
>> the USE statement.
> So a compiler might not write the MOD file (or however it got the
> data to subsequent USE) right away at the end of the module?
> Possibly not until EOF on the input source file?
You need to define what you mean by "write". A processor in theory
can process a module and keep the contents in memory or even
the aether. AFAIK, the standard only states that when a processor
processes a 'USE <module>' statement that whatever is needed from
<module> is available. In principle, one could build a multi-pass
processor that will recursively try to compile Fortran source possibly repeatly skipping a scoping unit until all modules are
available.
>>> It does say , in 11.2.1 of f2003,
>>> "At the time a USE statement is processed, the public portions of the
>>> specified module shall be available."
(snip, then I wrote)
>> So a compiler might not write the MOD file (or however it got the
>> data to subsequent USE) right away at the end of the module?
>> Possibly not until EOF on the input source file? > You need to define what you mean by "write". A processor in theory
> can process a module and keep the contents in memory or even
> the aether.
OK, "make available." Consider an example:
module this
integer :: i=3
end module this; use this
print *,i
end
Note that the USE is on the same line as the END MODULE.
If a compiler didn't "make available" the module until it finished
processing the line (record), then it wouldn't be ready for the USE.
Previously, I considered that it wouldn't be "available" until
the end of processing the given input file (reach EOF).
> AFAIK, the standard only states that when a processor
> processes a 'USE <module>' statement that whatever is needed from
> <module> is available. In principle, one could build a multi-pass
> processor that will recursively try to compile Fortran source > possibly repeatly skipping a scoping unit until all modules are
> available.
>>>> "At the time a USE statement is processed, the public portions of the
>>>> specified module shall be available."
> (snip, then I wrote)
>>> So a compiler might not write the MOD file (or however it got the
>>> data to subsequent USE) right away at the end of the module?
>>> Possibly not until EOF on the input source file?
>> You need to define what you mean by "write". A processor in theory
>> can process a module and keep the contents in memory or even
>> the aether.
> OK, "make available." Consider an example:
> module this
> integer :: i=3
> end module this; use this
> print *,i
> end
> Note that the USE is on the same line as the END MODULE.
Think in terms of scoping unit! The semicolon marks the end of
a statement. A processor can and some do process statements.
At the conclusion of processing the 'end module' statement, the
processor knows one scoping unit is complete and parsing has
started with a new scoping unit.
Steven G. Kargl <s...@removetroutmask.apl.washington.edu> wrote:
(snip, then I wrote)
>> OK, "make available." Consider an example:
>> module this
>> integer :: i=3
>> end module this; use this
>> print *,i
>> end >> Note that the USE is on the same line as the END MODULE.
> Think in terms of scoping unit! The semicolon marks the end of
> a statement. A processor can and some do process statements.
> At the conclusion of processing the 'end module' statement, the
> processor knows one scoping unit is complete and parsing has
> started with a new scoping unit.
Yes it is a different scoping unit, but so far I haven't seen
it required that the module information be available for the
new scoping unit right away. That is the question.
There used to be, and maybe still are, some funny restrictions
on END statements, such as no continuations. That might be to
avoid problems with record boundaries and scoping units.
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Yes it is a different scoping unit, but so far I haven't seen
> it required that the module information be available for the
> new scoping unit right away. That is the question.
And there is no answer. The standard is deliberately vague about such
things. If you are hoping for some actual answer with specifics about
how the standard allows implementations to act in this regard, you
aren't going to get it. I see little point in speculating about what
obscure things implementations might or might not do and whether the
standard says anything about it. Because I can answer the bit about what
the standard says without hearing the speculations. Yes, the standard
allows any such behaviors you might imagine and others that you probably
can't.
The standard just has a hint that dependencies can exist. That's really
all. I quoted the entire normative material from the standard on the
subject, although I recall there was some elaboration in the section
nores in an Annex.
-- Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
>> Yes it is a different scoping unit, but so far I haven't seen
>> it required that the module information be available for the
>> new scoping unit right away. That is the question.
> And there is no answer. The standard is deliberately vague about such
> things. If you are hoping for some actual answer with specifics about
> how the standard allows implementations to act in this regard, you
> aren't going to get it.
That is close enough for me.
> I see little point in speculating about what
> obscure things implementations might or might not do and whether the
> standard says anything about it. Because I can answer the bit about what
> the standard says without hearing the speculations. Yes, the standard
> allows any such behaviors you might imagine and others that you probably
> can't.
It is sometimes nice to have a specific example to discuss, but, yes,
it doesn't matter much either way.
> The standard just has a hint that dependencies can exist. That's really
> all. I quoted the entire normative material from the standard on the
> subject, although I recall there was some elaboration in the section
> nores in an Annex.
On Tue, 18 Sep 2012 16:19:13 +0200, Wolfgang Kilian wrote:
> On 09/18/2012 04:02 PM, jski wrote:
>> I was just exploring and playing with gfortran (I'm a newbie BUT very
>> impressed with Fortran vs. C for numerical coding).
>> But what about the order of the modules, if all the code is in 1 file?
> The compiler is likely (but, strictly speaking, not require to) compile
> the modules in the order that they have been written in the file. If
> the file looks like
> module a ...
> end module a
> module b
> use module a
> ...
> end module b
> everything is probably fine, because a.mod will be available in time for
> the compilation of b. But if the file looks like
> module b
> use module a
> ...
> end module b
> module a ...
> end module a
> a.mod will either not be available or, even worse, the compiler may read
> a file a.mod that was left over from a previous compilation. This may
> result in anything from everything ok, strange warnings, errors, to
> apparently successful compilation with wrong results (the worst case).
> So, make sure that the order is correct.
> -- Wolfgang
This seems logical in a way but in fact I think it is a
weakness of the compiler. We don't have to have defined a
function, for example, before we use it, so why are modules
different?
> a.mod will either not be available or, even worse, the compiler may read
> a file a.mod that was left over from a previous compilation. This may
> result in anything from everything ok, strange warnings, errors, to
> apparently successful compilation with wrong results (the worst case).
> So, make sure that the order is correct.
> -- Wolfgang
This seems logical in a way but in fact I think it is a
weakness of the compiler (or the Fortran definition?).
We don't have to have defined a function, for example,
before we use it, so why should modules be different?
I admit it's nice to have the module at the top, for an
easy overview of what we have up there.
-- Dieter Britz
