Modules and libraries
Pep Navarro
Hi,
My company has been working with FORTRAN 77 for 15 years now.
In all this time, we've created a pretty big number of support
libraries that our developers use in a regular way.
Now, we want to go to FORTRAN 90. I've been reading about
the new concepts in the languages and found that the MODULE
is a very interesting one, because it provides the way to
encapsulate both data and procedures in a single "box".
Modules are very good, but it seems that they only can be used
through an "USE" statement, which implies the availability
of the source code to developers in a more or less central
repository. Then my question is: is there any way to create
static libraries out of a module source? I've been trying to
do it with Fortran PowerStation 4.0 (for Windows NT) without
success. I guess that the module is not intended to be a
"procedure pool" (so you just can compile it and get a library
for regular use) but an encapsulation mechanism that programmers
must use in a way similar to the old, non portable INCLUDE
sentence (with more features, of course).
Please, excuse me if mine is a stupid question! I've just
began to browse my first FORTRAN 90 book. Thanks for your help.
Arnaud Desitter
Pep Navarro wrote:
>
> Hi,
>
> My company has been working with FORTRAN 77 for 15 years now.
> In all this time, we've created a pretty big number of support
> libraries that our developers use in a regular way.
>
> Now, we want to go to FORTRAN 90. I've been reading about
> the new concepts in the languages and found that the MODULE
> is a very interesting one, because it provides the way to
> encapsulate both data and procedures in a single "box".
>
> Modules are very good, but it seems that they only can be used
> through an "USE" statement, which implies the availability
> of the source code to developers in a more or less central
> repository.
A module is a compiling unit. Using 'use my_module' implie that
a reference must be solved by the linker and, so, that :
- either you compile at the same time the module source code
- either you give the path to find the object file of your module
in a librarie.
I do not understand very well the meaning of "the availability of the
source code to developers".
Indeed, if you are calling a subroutine (or function), you must know
which arguments you have to put in your call. This does not imply
at all you need the source code of the subroutine but only the
listing of its header.
In fact, you can see modules as the equivalent of the #include in C,
whith one difference : in C it is preprocessed ("wordprocessing
before compilation"), in Fortran, it's precompiled.
In modules you can choose to only put the headers of your
subroutines (with interface) or include the complete code of them.
The problem with the second solution is that it can increase the
size of your executable code if your compiler is not too clever.
> Then my question is: is there any way to create
> static libraries out of a module source? I've been trying to
> do it with Fortran PowerStation 4.0 (for Windows NT) without
> success. I guess that the module is not intended to be a
> "procedure pool" (so you just can compile it and get a library
> for regular use) but an encapsulation mechanism that programmers
> must use in a way similar to the old, non portable INCLUDE
> sentence (with more features, of course).
In fortran 90, 'include' is standard, so if you have got old sources
using it, they are now portable. Nice, isn't it ?
Steve Lionel
In article <5gitqc$oh2$1...@mhafn.production.compuserve.com>, Pep Navarro
<10042...@CompuServe.COM> writes:
|>Modules are very good, but it seems that they only can be used
|>through an "USE" statement, which implies the availability
|>of the source code to developers in a more or less central
|>repository. Then my question is: is there any way to create
|>static libraries out of a module source? I've been trying to
|>do it with Fortran PowerStation 4.0 (for Windows NT) without
|>success. I guess that the module is not intended to be a
|>"procedure pool" (so you just can compile it and get a library
|>for regular use) but an encapsulation mechanism that programmers
|>must use in a way similar to the old, non portable INCLUDE
|>sentence (with more features, of course).
You ought to be able to compile MODULEs separately, giving you .m (or .mod or
whatever) files that are USEd, without the requirement that the source be
around. Some compilers (I didn't think PowerStation was among them) might
not implement it this way, but Digital's compilers certainly do. There will
typically be object modules that correspond to the compiled module source,
but you shouldn't have to keep the .f90 source around.
Try this. Compile the MODULE file separately, don't insert the source for it
in the Developer Studio "project" - you can insert the .mod or name the
directory in the project settings module path (it's under Miscellaneous in
DIGITAL Visual Fortran - I don't know where it is in PowerStation.) I was
able to successfully compile a source that USEd a .mod file whose source
was unavailable.
--
Steve Lionel mailto:lio...@quark.zko.dec.com
Fortran Development http://www.digital.com/info/slionel.html
Digital Equipment Corporation
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"
For information on DIGITAL Fortran, see http://www.digital.com/fortran
James Giles
Pep Navarro wrote:
[...]
> Modules are very good, but it seems that they only can be used
> through an "USE" statement, which implies the availability
> of the source code to developers in a more or less central
> repository. [...]
The section notes for the Fortran 90 standard contain a long commentary
about dependent compilation and MODULEs (C.11.2). The bottom line,
though, is the following:
The exact meaning of the requirement that the public portions
of a module be available at the time of reference is processor
defined. For example, a processor could consider a module to
be available only after it has been compiled and require that
if the module has been compiled separately, the result of that
compilation must be identified to the compiler when compiling
program units that use it.
The most important part of this is the phrase "processor dependent".
This essentially means that the compiler can make any rules it wants -
including the requirement that MODULE source be available. In practice,
most compilers follow the example given in the second sentence above: if
you separately compile your MODULE, you must do so before you compile
any USEs of that MODULE and you must make the location of the compiled
MODULE known to the compiler when compiling any USEs.
I personally think the Fortran 90 rule is too restrictive. It limits
the ability to incrementally design and implement your programs and/or
to maintain them independently. For example:
MODULE DEMO
CONTAINS
REAL FUNCTION AVE(X, Y)
REAL X, Y
AVE = (X+Y)/2.0
RETURN
END FUNCTION AVE
END MODULE DEMO
Suppose I decide to change the computation of AVE so that it does the
following:
AVE = X + (Y-X)/2.0
This is a good idea if the arguments are known to always have the same
sign and you fear they might be near overflow. However, if you make
this change, you can't just recompile the module and relink all the
codes that USE it. Even though none of the externally visible
properties of the MODULE have changed (like the declarations of type,
number of arguments, etc.) you must still actually recompile all program
units that USE the module.
This implies a considerable increase in overhead compared to maintaining
old-fashioned libraries. Any internal maintenance to a library merely
required relinking all the programs that used the library - not
recompilation of them.
--
J. Giles
Ricercar Software
William Clodius
James Giles wrote:
> <snip> Even though none of the externally visible
> properties of the MODULE have changed (like the declarations of type,
> number of arguments, etc.) you must still actually recompile all program
> units that USE the module.
This is a quality of implementation issue, in which most (all?) current
compilers/developement environments for Fortran 90 have poor quality.
In principle, the development environment could maintain a database
containing the appropriate interface/entity data type descriptions on a
per module basis and only force a recompilation for those codes that
rely on those interfaces, etc. that have changed.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
Dieter Britz
On 17 Mar 1997, Steve Lionel wrote:
[...]
> You ought to be able to compile MODULEs separately, giving you .m (or .mod or
> whatever) files that are USEd, without the requirement that the source be
> around. Some compilers (I didn't think PowerStation was among them) might
> not implement it this way, but Digital's compilers certainly do. There will
> typically be object modules that correspond to the compiled module source,
> but you shouldn't have to keep the .f90 source around.
>
> Try this. Compile the MODULE file separately, don't insert the source for it
> in the Developer Studio "project" - you can insert the .mod or name the
> directory in the project settings module path (it's under Miscellaneous in
> DIGITAL Visual Fortran - I don't know where it is in PowerStation.) I was
> able to successfully compile a source that USEd a .mod file whose source
> was unavailable.
I think we're getting somewhere here, but I would like to be quite clear on
this (it wasn't me asking the original question but I have the same problem).
I write a lot of f90 programs, in various directories according to the
project. I also have a subroutine library in a central directory, full of
compiled units. Common between all my programs and the library routines is my
little set of KIND definitions (I might add more later, like pi as a
parameter etc), where I define the parameters SINGLE and DOUBLE with the
precisions I want. So I compile each subroutine using this module, as well
as every program. Am I correct in assuming from what you write that if I
compile the module in the working directory (it's called STUFF), leaving
behind the file stuff.mod, I can "use" it in the program if I name it in the
compile/link statement, and that this will link up with its use at
compile-time for the library routines? I use unix, so the statement would be
something like
f90 proggie.f90 stuff.mod -Lf90lib -lf90lib
(i.e. I have the object library, libf90lib.a in the directory f90lib, and
stuff.mod in the working directory - it might actually be better placed in
the library directory). Is this correct?
Doesn't this complicate the commercial subroutine business? Packages such as
that of NAG would now have to tell us what precision they have defined or,
preferably, supply the source text (and/or compiled code) for the module used
in conjunction with all the routines.
------------------------------------------------------------------------------
| Dieter Britz alias br...@kemi.aau.dk |
| Kemisk Institut, Aarhus Universitet, 8000 Aarhus C, Denmark. |
| Telephone: +45-89423874 (8:30-17:00 weekdays); fax: +45-86196199 |
| http://www.kemi.aau.dk/~britz |
------------------------------------------------------------------------------
Pep Navarro
Dear James,
It seems that it's worse I ever imagined. Your answer seems
to state that it is NOT possible to use what you call "old
fashioned" and I think are "very useful" libraries when
dealing with modules.
The recompilation problem is really a PROBLEM 8-(
Good Lord! Do you have any idea about whether Fortran 95
copes with this problem?
Thanks alot, James.
Pep.
James Giles
Pep Navarro wrote:
[...]
> It seems that it's worse I ever imagined. Your answer seems
> to state that it is NOT possible to use what you call "old
> fashioned" and I think are "very useful" libraries when
> dealing with modules.
>
> The recompilation problem is really a PROBLEM 8-(
I agree. It may seem to some to be a minor inconvenience to have to
recompile. But, in some instances, it's not even possible. Suppose you
buy software from two different vendors: you buy a module of graphics
routines from one vendor, and a module of statistics routines from
another. Suppose further that the statistics module uses the graphics
module also (maybe that's why you bought it - it uses the same graphics
the rest of your code does). Now, if the graphics vendor comes out with
new revision, you can't incorporate that into your programs unless the
statistics vendor supplied you with source code! Without modules, you
could incorporate the new stuff by just relinking.
> Good Lord! Do you have any idea about whether Fortran 95
> copes with this problem?
The (proposed) Fortran 95 standard document has the same language the
Fortran 90 document does (though they've moved it around a bit).
Your only solution is to continue coding your libraries as ordinary
external subprograms. You can still use modules, but mainly only to
contain public data and type declarations. And, without modules you
*can't* share private data, code, or types within your library. But,
you've never had shared private objects before F90 anyway.
James Giles
William Clodius wrote:
[...]
> This is a quality of implementation issue, in which most (all?) current
> compilers/developement environments for Fortran 90 have poor quality.
> In principle, the development environment could maintain a database
> containing the appropriate interface/entity data type descriptions on a
> per module basis and only force a recompilation for those codes that
> rely on those interfaces, etc. that have changed.
There are three problems with this argument. The first two are generic
to all "quality of implementation" arguments:
1) If you depend on a "quality of implementation" feature, your code
will not be portable.
2) The "quality of implementation" argument is never raised unless the
standard has been imprecise, incomplete, or otherwise poorly defined.
Sometimes this is unavoidable (like number representations, or allowed
file names). But for things entirely within the discretion of the
standard (like rules about dependent compilation) it seems unnecessary
to be imprecise. Probable result of committee-speak.
The third problem with the "quality of implementation" argument is
specific to this issue alone:
3) The last time I raised this issue in this forum the consensus was the
other way around! It was regarded as a important test of the "quality
of implementation" whether a compiler used dependent compilation to do
interprocedural analysis (possibly even inlining).
In answer to this third point, I must say that I favor (strongly) the
possibility of interprocedural analysis (even inlining) as an option
under the control of the user. It should certainly not be the default
behavior of MODULEs. As presently defined, the principle value of
MODULEs is as a scoping tool. It's irritating that I can't get that
particular functionality without also getting stuck with dependent
compilation.
Loren Meissner
You probably can't convert a library of F77 programs into F90 modules
unless you have the source code for the library.
=
However, once you have the F77 library source code, you can put all
the library procedures into modules, compile the modules, and never
look at the source code again. [The standard leaves it open, but all
F90 systems that I know of will let you link to a previously compiled
module.]
=
Mike Metcalf did this at CERN several years ago, when F90 had just
come out, with a minimum of difficulty. <met...@cern.ch>
=
Fortran 95, which is finally about to become an official standard,
makes only minor changes - mostly enhanced parallelization, and
initialization of structures and pointers. No change in the area of
modules and how they are used.
=
Loren P. Meissner
<LPMei...@msn.com>
daveg...@aol.com
MS FPS does NOT require users to have the source code in order to
USE AMODULE
Example: PORTLIB.MOD is the compiled output of PORTLIB.F90
(interface to the PORTLIB.LIB)
MOD files under FPS are readable text that one can decipher.
USE PORTLIB
in a routine does not require compiler to have access to PORTLIB.F90
Pirmin Kaufmann
Pep Navarro wrote:
>
> Dear James,
>
> It seems that it's worse I ever imagined. Your answer seems
> to state that it is NOT possible to use what you call "old
> fashioned" and I think are "very useful" libraries when
> dealing with modules.
>
> The recompilation problem is really a PROBLEM 8-(
I don't think the situation is THAT bad. If the interface of a procedure
doesn't change, there is no need to recompile the main program. Of
course you have to recompile the procedure itself, just as you had to do
for the library as well.
On Unix, I put the .M file containing the compiled procedure interfaces
along with the static library .lib file in a directory which is in the
linker path (LD_LIBRARY_PATH). At least, Sun's f90 finds it there.
Someone else has already pointed out how to ad a .mod file in FPS if you
don't have the source code. If you do have the module source, add it to
the project, and you're done.
The thing I don't like is that I have to make an extra file (the module
file) containing the interfaces. What if I change the argument list in
the procedure file and forget to change the interface in the module
file? To avoid this, I put not only the interfaces, but the whole
procedures into the module, using INCLUDE statements:
module xxx
contains
include 'sub_1.f90'
include 'sub_2.f90'
end module
I don't use the object of the module, only the .M or .mod (or whatever)
file along with the library. Not very elegant, but I haven't figured out
anything nicer yet.
Pirmin
------------------------------------------------
Pirmin Kaufmann pkau...@etl.noaa.gov
NOAA/ERL/ETL phone: 303 497-6613
325 Broadway R/E/ET7 fax: 303 497-6978
Boulder, CO 80303-3328
------------------------------------------------
James Giles
Pirmin Kaufmann wrote:
[...]
> I don't think the situation is THAT bad. If the interface of a procedure
> doesn't change, there is no need to recompile the main program. [...]
That's not what the standard says. You may have a particular
implementation which does not require recompilation of the USErs of a
changed MODULE, but the standard *does* require it. This is true even
if the changes to the module don't alter its interfaces and/or its
public types and data objects. The standard is a little fuzzy about the
need to recompile the USErs of a MODULE is when PRIVATE data was
changed.
Of course, you can continue to use your implementation which doesn't
require recompilation unless interfaces change - you're just flirting
with disaster if you come to *rely* on that method of operation. And,
again, I'll point out that I think the standard should have clearly
*permitted* changing non-interface parts of a MODULE without requiring
recompilation of USEs.
James Giles
Richard Maine wrote:
>
> James Giles <JGi...@cris.com> writes:
[...]
> > That's not what the standard says. You may have a particular
> > implementation which does not require recompilation of the USErs of a
> > changed MODULE, but the standard *does* require it.
>
> I disagree with this interpretation of the standard. I see no
> support at all for this statement in the standard. The standard
> certainly *allows* implementations that require recompilation,
> but I don't even see a hint that it requires it. [...]
The standard doesn't require *implementations* to do anything particular
at all. It required conforming programs to have certain properties. In
this case, conforming programs must *not*rely* on being able to
independently compile modules - even if the only thing the module
changed was not part of the interface information. As stated before in
this thread, the constreaint allows implementations to inline (or do
other interprocedural analysis) which would obviously break if the user
tries to recompile *ONLY* the module and then relink.
So, if you want to distribute portable code, you must *NOT* rely on
being able to just relink changed Modules. Period.
Richard Maine
James Giles <JGi...@cris.com> writes:
> Pirmin Kaufmann wrote:
> > I don't think the situation is THAT bad. If the interface of a procedure
>
> That's not what the standard says. You may have a particular
> implementation which does not require recompilation of the USErs of a
> changed MODULE, but the standard *does* require it.
I disagree with this interpretation of the standard. I see no
support at all for this statement in the standard. The standard
certainly *allows* implementations that require recompilation,
but I don't even see a hint that it requires it. The main relevant
citation is section 11.3.1, second sentence
"At the time a module reference is processed, the public portions
of the specified module must be available."
The section notes (not technically a normative part of the standard)
elaborate on this. The last paragraph of C.11.2 says
"The exact meaning of the requirement that the public portions
of a module be available at the time of reference is processor
defined. For example, a processor could consider a module to
be available only after it has been compiled and require that
if the module has been compiled separately, the result of that
compilation must be identified to the compiler when compiling
program units that use it."
I have difficulty in seeing how anyone could read the explicit
statement that "the meaning of the requirement...is processor
defined" and come to the conclusion that the standard requires
recompilation of the USErs of a changed module. The last
quoted sentence above is pretty explicit about being only an
example of a possible processor implementation. (It is hard
to be much more explicit than "For example, a processor could...").
I don't have the time to debate such questions as whether the
standard should have said something different. Such discussions
of opinion are never-ending. However, I believe the claim that
the standard requires recompilation to be factually incorrect
and thus worth correcting so that it is not propogated.
If someone has any citations to suggest otherwise, I'd like to
see them. If someone can manage to read the above citations
in such a strange way as to support the claim that the standard
requires this, then I'm not sure we are speaking the same language.
Note that I agree that the standard *allows* such implementations
(that seems pretty explicit). And I'd also agree that a user
cannot safely assume that recompilation is not needed. This is
not the same thing as saying that the standard requires recompilation.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
Pirmin Kaufmann
James Giles wrote:
[...]
> The standard doesn't require *implementations* to do anything particular
> at all. It required conforming programs to have certain properties. In
> this case, conforming programs must *not*rely* on being able to
> independently compile modules - even if the only thing the module
> changed was not part of the interface information. As stated before in
> this thread, the constreaint allows implementations to inline (or do
> other interprocedural analysis) which would obviously break if the user
> tries to recompile *ONLY* the module and then relink.
>
> So, if you want to distribute portable code, you must *NOT* rely on
> being able to just relink changed Modules. Period.
This might apply to procedures contained in modules. However, remember
that the original post was asking about the use of modules in
conjunction with libraries. So if a module consists of the _interfaces_
to the procedures in the library only, then the module doesn't change if
the library procedure body changes, and your statement doesn't apply.
Your point leads to the conclusion that it is better to put the
interfaces only into the module rather than the bodies of the
procedures. Keep the procedures in a library, which can be compiled
seperately and independently, and make an interface module. This way one
has the benefit of both, modules and libraries.
James Giles
Pirmin Kaufmann wrote:
[...]
> Your point leads to the conclusion that it is better to put the
> interfaces only into the module rather than the bodies of the
> procedures. Keep the procedures in a library, which can be compiled
> seperately and independently, and make an interface module. This way one
> has the benefit of both, modules and libraries.
Yes, that is exactly the advice I have given numerous times in the
past. However, this does not provide all the advantages of MODULEs. In
particular, an data which you want to share between procedures in your
library must be made global. This means that the user of the library
can (inadvertently or deliberately) make use of that shared data
directly, even if it was the library writer's intent that it be private
to the library.
It would have been preferable if the standard had explicitly defined the
bodies of MODULE procedures to be PRIVATE by default (even if their
interfaces were PUBLIC). Then, you could share PRIVATE data among your
procedures and still enjoy the benefit of separate compilation (provided
your interfaces don't change). The standard doesn't do that. Hence the
problem being discussed in this thread.
William Clodius
James Giles wrote:
>
> <snip>
>
> The standard doesn't require *implementations* to do anything particular
Quoting Richard Maine's quote of the standard
"The exact meaning of the requirement that the public portions
of a module be available at the time of reference is processor
defined. For example, a processor could consider a module to
be available only after it has been compiled and require that
if the module has been compiled separately, the result of that
compilation must be identified to the compiler when compiling
program units that use it."
The term "processor defined" does require *implementations* to do
something in particular, they must define what assumptions users can
make in relinking changed modules. This changes your statement
> So, if you want to distribute portable code, you must *NOT* rely on
> being able to just relink changed Modules. Period.
to
If you want to distribute portable code, you can only rely on being able
to just relink changed Modules if the compiler explicitly provides that
option and the code has been compiled in a manner consistent with that
option.
Van Snyder
In article <333185...@etl.noaa.gov>, Pirmin Kaufmann <pkau...@etl.noaa.gov> writes:
|> .... So if a module consists of the _interfaces_
|> to the procedures in the library only, then the module doesn't change if
|> the library procedure body changes, and your statement doesn't apply.
|>
|> Your point leads to the conclusion that it is better to put the
|> interfaces only into the module rather than the bodies of the
|> procedures. Keep the procedures in a library, which can be compiled
|> seperately and independently, and make an interface module. This way one
|> has the benefit of both, modules and libraries.
This is exactly the reason for having separate interface and specification
in Modula and Ada, and the reason I proposed it for Fortran in 1986. I
proposed it again in February, and it was finally agreed it's a good idea,
but it landed in the "good idea but not enough time" list. Maybe in 2007?
--
What fraction of Americans believe | Van Snyder
Wrestling is real and NASA is fake? | vsn...@math.jpl.nasa.gov
Clive Page
In article <332DBA...@cris.com>, James Giles <JGi...@cris.com> wrote:
>
>This implies a considerable increase in overhead compared to maintaining
>old-fashioned libraries. Any internal maintenance to a library merely
>required relinking all the programs that used the library - not
>recompilation of them.
>
Another way of doing things, which I think has been used by some commercial
libraries re-issued for Fortran90, is to leave their routines as an object
library as they always were, but to release separately a MODULE as a
source file containing all the INTERFACE definitions of every
user-callable routine. This file doesn't give away all their secrets,
doesn't have much of an overhead on compilation, but ensures that all
users get the interfaces checked. What it doesn't do is make sure that
the internal interfaces between one routine and its dependent routines in
the same library are checked - but if the library is well-established
working code, that is perhaps a luxury (or something the vendors can check
before release in a separate bit of code development). This isn't an
ideal solution, as it means a potential problem if a user-callable
procedure changes its interface without a corresponding change to the
INTERFACE in the released MODULE. But such changes are rare in released
commercial libraries, for obvious reasons.
--
-------------------------------------------------------------------------
Clive Page, Internet: c...@star.le.ac.uk
Dept of Physics & Astronomy,
University of Leicester.
James Giles
Clive Page wrote:
>
[...]
>
> Another way of doing things, which I think has been used by some commercial
> libraries re-issued for Fortran90, is to leave their routines as an object
> library as they always were, but to release separately a MODULE as a
> source file containing all the INTERFACE definitions of every
> user-callable routine. This file doesn't give away all their secrets,
> doesn't have much of an overhead on compilation, but ensures that all
Unfortunately, it gives up what I consider to be the most interesting
aspect of MODULEs - PRIVATE variables. Any variable, constant, or data
type shared by separately compiled object code must either be in a
COMMON block or must be PUBLIC in a MODULE. This makes it possible for
the user code to (deliberately or accidentally) use those objects
directly. By combining the functionality of interface checking with the
functionality of scope restriction into the same tool, the committee has
diminished the value of both.
Jean Vezina
The problem of excessive recompilation could be solved if the following
logic was added to compilers and make utilities:
For compilers, each time a module is recompiled, a check should be
done if interfaces and declarations are changed by writing the contents
of *.mod or *.m file to a temporary file and comparing the contents
of this file to the previous module definition file. If the contents
are changed, the *.mod or whatever are updated and, in this case,
recompilation of program units that use this modules is required.
But, if nothing is modified, only the object file is changed and
relinking is sufficient. This case will occur if changes are done only
in the computational part of the module procedures.
The make utilities will have to check the *.mod and the object files
instead to determine the rebuild operation instead of the source
files. Recompilation is needed only for source files that use modules
with changed *.mod files.
This logic cannot apply, of course, for compilers that performs
interprocedural optimizations and inlining over different source
files. In this case, recompilation is always required.
Sincerely,
Jean Vezina
David Singleton
In article <33375C...@ibm.net>, Jean Vezina <jve...@ibm.net> writes:
|>
|> For compilers, each time a module is recompiled, a check should be
|> done if interfaces and declarations are changed by writing the contents
|> of *.mod or *.m file to a temporary file and comparing the contents
|> of this file to the previous module definition file. If the contents
|> are changed, the *.mod or whatever are updated and, in this case,
|> recompilation of program units that use this modules is required.
|> But, if nothing is modified, only the object file is changed and
|> relinking is sufficient. This case will occur if changes are done only
|> in the computational part of the module procedures.
|>
Its not hard to write shell and awk scripts to do exactly this
particularly if you tailor them to your programming style. The only
constraint I have on my code is separating the interface information
from the local information of each procedure with a specific comment
line. Then the scripts are quite simple.
----------------------------------------------------------------------------
Dr David Singleton ANU Supercomputer Facility
David.S...@anu.edu.au Australian National University
Work Phone: +61 6 249 4389 Canberra, ACT, 0200, Australia
Home Phone: +61 6 248 7142 Fax: +61 6 279 8199
----------------------------------------------------------------------------
Van Snyder
In article <332EEF...@cris.com>, James Giles <JGi...@cris.com> writes:
|> Pep Navarro wrote:
|>
|> [...]
|>
|> > It seems that it's worse I ever imagined. Your answer seems
|> > to state that it is NOT possible to use what you call "old
|> > fashioned" and I think are "very useful" libraries when
|> > dealing with modules.
|> >
|> > The recompilation problem is really a PROBLEM 8-(
|>
|> recompile. But, in some instances, it's not even possible. Suppose you
|> buy software from two different vendors: you buy a module of graphics
|> routines from one vendor, and a module of statistics routines from
|> another. Suppose further that the statistics module uses the graphics
|> module also (maybe that's why you bought it - it uses the same graphics
|> the rest of your code does). Now, if the graphics vendor comes out with
|> new revision, you can't incorporate that into your programs unless the
|> statistics vendor supplied you with source code! Without modules, you
|> could incorporate the new stuff by just relinking.
|> Your only solution is to continue coding your libraries as ordinary
|> external subprograms. You can still use modules, but mainly only to
|> contain public data and type declarations. And, without modules you
|> *can't* share private data, code, or types within your library. But,
|> you've never had shared private objects before F90 anyway.
This discussion describes _exactly_ the reason that I advocated separate
interface and implementation modules for Fortran, starting with S8.99, and
all the way up to the final public review for what became Fortran 90.
This was _not_ untried technology at the time. Modula and Ada already had
separate interface and implementation modules. I had already written several
compilers in both languages, and knew the advantages of this kind of separate
packaging.
I proposed it again in February at the joint WG5/X3J3 meeting. It was
finally agreed that it's a good idea, but it got lost on "the cutting room
floor" when changes were prioritized to fit into the November 2002 schedule.
I don't think it's difficult to add, and still preserve compatibility to
Fortran 90. See hppt://gyre.jpl.nasa.gov/~vsnyder/fortran/modules.html
Becky & Greg Jaxon
James Giles wrote:
>
> Clive Page wrote:
> > Another way of doing things is to release separately a MODULE as a
> > source file containing all the INTERFACE definitions of every
>
> Unfortunately, it gives up PRIVATE variables.
> type shared by separately compiled object code must either be in a
> COMMON block or must be PUBLIC in a MODULE.
> This makes it possible for
> the user code to (deliberately or accidentally) use those objects
> directly.
The library's facade MODULE could declare the PRIVATE types and
variables if the interfaces need them. Many forward looking F9x
compilers permit the use of PRIVATE entities within PUBLIC interfaces.
The standard even allowed PRIVATE subfields of PUBLIC types, which
it structurally no different.
I can't reconcile the idea that these entities embody the library's
"secrets" with the fact that they are essential parts of its external
interface.
Greg Jaxon
Kuck & Associates, Inc.
Viggo Norum
Jean Vezina <jve...@ibm.net> writes:
>
> The problem of excessive recompilation could be solved if the following
> logic was added to compilers and make utilities:
No, it does not solve the problem.
It will work, but it will give many unnecessary recompilations.
It is one step in the right direction, in fact this is the method used
by some of the most "advanced" F90 tools, but it has BIG flaws.
>
> For compilers, each time a module is recompiled, a check should be
> done if interfaces and declarations are changed by writing the contents
> of *.mod or *.m file to a temporary file and comparing the contents
> of this file to the previous module definition file. If the contents
> are changed, the *.mod or whatever are updated and, in this case,
> recompilation of program units that use this modules is required.
> But, if nothing is modified, only the object file is changed and
> relinking is sufficient. This case will occur if changes are done only
> in the computational part of the module procedures.
>
> The make utilities will have to check the *.mod and the object files
> instead to determine the rebuild operation instead of the source
> files. Recompilation is needed only for source files that use modules
> with changed *.mod files.
>
Imagine that you use a library and you include it's .mod file in the
dependency check. Then someone adds a subroutine to the library, and
you happily(?) recompile all modules/programs using that library, also
those not using that subroutine!!!
>
> This logic cannot apply, of course, for compilers that performs
> interprocedural optimizations and inlining over different source
> files. In this case, recompilation is always required.
No, it's not. If the compiler kept a log of inlined code, it could
easily check if a routine needs recompilation and skip the recompila-
tion of dependent code if no inlining was done of an edited routine.
> Sincerely,
>
> Jean Vezina
Compiler designers/developers: Please, PLEASE include good automatic
dependency checking and recompilation in the compilers, and let us
get rid of those time wasting tools for dependency checking.
Let compiling large programs be as easy as: f90 mainprog.f90
Also: Good Fortran 90 compilers should recompile only the edited
*parts* of modules. Say you edit one of 50 subroutines in a module,
then only that subroutine and modules/programs using that subroutine
in the edited module should be recompiled.
--
Viggo L. Norum
Jeffrey Templon
Viggo Norum <vig...@immpc20.marina.unit.no> writes:
> Compiler designers/developers: Please, PLEASE include good automatic
> dependency checking and recompilation in the compilers, and let us
> get rid of those time wasting tools for dependency checking.
> Let compiling large programs be as easy as: f90 mainprog.f90
They should do this *only* if there is some agreed-upon standard.
Right now I am working on a code which has *many* different modules,
and which has to run on the following soup of machines:
ix86/linux
SPARC/Solaris
PA-Risc/HP-UX
Alpha/OSF1
RS/6000/AIX
no way I'd touch a proprietary automatic dependency checker. It would
have to be the same on all these platforms. Otherwise, I'll just
stick to make, as flawed or not as it may be.
JT
Viggo Norum
Jeffrey Templon <tem...@studbolt.physast.uga.edu> writes:
>
> Viggo Norum <vig...@immpc20.marina.unit.no> writes:
>
> > Compiler designers/developers: Please, PLEASE include good automatic
> > dependency checking and recompilation in the compilers, and let us
> > get rid of those time wasting tools for dependency checking.
> > Let compiling large programs be as easy as: f90 mainprog.f90
>
> They should do this *only* if there is some agreed-upon standard.
What I suggested is so easy that neither the compiler developers nor
the compiler users should go wrong: f90 mainprog.f90
> Right now I am working on a code which has *many* different modules,
> and which has to run on the following soup of machines:
>
> ix86/linux
> SPARC/Solaris
> PA-Risc/HP-UX
> Alpha/OSF1
> RS/6000/AIX
Yes, and if one of those machines had a very good dependency check in
their compiler and let you recompile your projects in way far more
efficient than the others, then that machine would become your
main/favorite development platform, would it not? You could of
course still use Makefiles on the other platforms.
>
> no way I'd touch a proprietary automatic dependency checker. It would
> have to be the same on all these platforms. Otherwise, I'll just
> stick to make, as flawed or not as it may be.
>
So you trust the compiler to compile the code, but "no way" it can do
the dependency checking?
Different f90 compilers need different dependency checking (because of
differences in use of .mod files, inlining of code, etc.). In order
to do efficient dependency checking in f90, the dependency tool will
have to:
* Parse the code and keep a log of what is used where.
* Split the code into smaller units and check for changes in each unit.
* Know much about the compiler internals of the specific compiler.
The compilers already parse the code and split it into smaller
units and the compiler developers know all about the compiler
internals, thus the compiler should do the dependency check.
As it is now, I (and many others I guess) are reluctant to use modules
in large projects because of the time to recompile. During a project
I recompile hundreds of times: I edit, recompile, test, edit, .....
--
Viggo L. Norum
William Clodius
Jeffrey Templon wrote:
>
> Viggo Norum <vig...@immpc20.marina.unit.no> writes:
>
> > Compiler designers/developers: Please, PLEASE include good automatic
> > dependency checking and recompilation in the compilers, and let us
> > get rid of those time wasting tools for dependency checking.
> > Let compiling large programs be as easy as: f90 mainprog.f90
>
> They should do this *only* if there is some agreed-upon standard.
Standard in what sense, and how will it be standardized? Standardiztion
occurs through three means, defacto standardization where one
organization implements the desired capability and others imitate or buy
the technology, consortiums where groups get together to define desired
capabilities, or de jure through the various international
standardization committees. Your restriction eliminates de facto
standardization. I note below that you are working exclusively on UNIX
workstations. The Fortran standardization committees are not concerned
with UNIX exclusive standardization, POSIX is not interested in Fortran
standardization. If I were on the Fortran standardization committee I
would not even want to begin thinking about standardizing this for all
OS's. De jure standardization of this capability therefore appears to be
impractical. That leave a consortium approach, but those have usually
(HPF is an exception) broken down into competing consortia, particularly
when the standardization involves user interface issues such as this.
> Right now I am working on a code which has *many* different modules,
I thought you were working only on F77 code where the concept of module
is not defined, although sometimes the term module is used as synonymous
with the term file. If you are still working on F77 than most of the
issues that concern Vigo and others who work with F90 do not affect you
at this time.
> and which has to run on the following soup of machines:
>
> ix86/linux
> SPARC/Solaris
> PA-Risc/HP-UX
> Alpha/OSF1
> RS/6000/AIX
>
> no way I'd touch a proprietary automatic dependency checker. It would
> have to be the same on all these platforms. Otherwise, I'll just
> stick to make, as flawed or not as it may be.
>
> JT
How does a proprietary interface on one platform hurt you on other
platforms? What would complicate your life is a reliance on an interface
that is not available to your users, and does not generate the
appropriate makefiles. I note that you have sometimes spoken well of
Eiffel, whose comercial implementations rely extensively on proprietary
dependency checkers.
James Giles
This whole recent discussion demonstrates one of the things which is
least productive about modern programming methodology: once a problem is
identified, rather than fix the problem people always demand additional
requirements on existing software and/or new utilities to "work around"
the problem. No wonder we have computing environments which are
increasingly big, slow, complex, hard to use, and buggy.
The problem here is that MODULES grouped several distinct useful
capabilities into a single feature. This means the programmer cannot
separately and explicitly control each of these capabilities. What's
needed is *NOT* lots of complex dependency analysis in the compilers or
new and complicated forms of 'make' (which itself is a workaround to
problems earlier on). Even if these solutions were adopted they would
be subtly different from one implementation to another and would,
therefore, not be reliable or portable. It just adds another layer of
complexity to the programming environment.
The solution to the problem is to decrease the amount of dependency
between MODULEs and their USErs. Identify that part of the declaration
of a MODULE which is needed by the USErs of those MODULEs at compile
time. Place that interface information into a separate source which
must be available to both the MODULE and its USErs at their respective
compile times. Provided that interface information doesn't change, the
MODULE and its USErs may be compiled, changed, and/or recompiled in any
order and the code can simply be relinked. Yes, this *is* what Ada and
several other languages already do.
As for inlining and aggressive interprocedural analysis, that is an
issue which *should* be distinct from the MODULE feature. To be sure,
since MODULE code is all grouped together, such aggressive techniques
should be applied *within* the MODULE. The other place such techniques
should be routinely applied is for internal procedures. Any procedure
contained within another should have all such aggressive techniques
within the skill of the compiler vendor applied to them - both for calls
from the containing routine as well as calls among themselves. You
could have a library of routines which are intended to be inlined (or
otherwise aggressively analyzed) in the form of text files which can be
INCLUDEd into the source of the procedures which call them.
With the above solution in place, even the simplist 'make' utility can
resolve the dependencies without lots of auxilliary analysis and there
is no particular burden placed on the compiler or 'make' to maintain
'.mod.' information files of elaborate description. Such solutions
(both of which have been recommended in this discussion) don't directly
address the problem and have the flavor of arcane, complex workarounds.
There's too much of that in this business.
Note also that INCLUDE and USE have completely different effects. I
have never been among those who believed that INCLUDE was redundant. It
does something completely distinct from MODULE/USE - as this example
clearly demonstrates. Having said that, INCLUDE *is* redundant with any
good text editor. Macros which perform INCLUDE should be easy to write
in any modern editor. So, if the committee chooses to delete INCLUDE in
some future standard, they're certainly wrong, but who cares?
Viggo Norum
James Giles <JGi...@cris.com> writes:
>
> This whole recent discussion demonstrates one of the things which is
> least productive about modern programming methodology: once a problem is
> identified, rather than fix the problem people always demand additional
> requirements on existing software and/or new utilities to "work around"
> the problem.
Nope, the "solution" you suggest is only workaround cluttering.
I would define your solution to be a brute force method, and the
method of investigating the dependencies to be a more intelligent
method.
Honestly: Who is "working around" and who is not can be discussed,
the statements above (mine too) are bad examples of subjectivity.
We agree that the feature called "automatic interfaces between
modules" is causing problems. You suggest not using that feature.
I suggest way of using it without the problems it causes.
> No wonder we have computing environments which are
> increasingly big, slow, complex, hard to use, and buggy.
>
Yes, no wonder it's slow and hard to use --- we are
using arcane tools on a modern programming language.
> The problem here is that MODULES grouped several distinct useful
> capabilities into a single feature.
That is not a problem, it sounds very good actually.
> This means the programmer cannot
> separately and explicitly control each of these capabilities. What's
> needed is *NOT* lots of complex dependency analysis in the compilers or
It *IS* needed as long as automatic interfaces between modules are used.
> new and complicated forms of 'make' (which itself is a workaround to
> problems earlier on). Even if these solutions were adopted they would
> be subtly different from one implementation to another and would,
> therefore, not be reliable or portable. It just adds another layer of
> complexity to the programming environment.
>
It would not be any problem if the tools were good and easy to use.
> The solution to the problem is to decrease the amount of dependency
> between MODULEs and their USErs. Identify that part of the declaration
> of a MODULE which is needed by the USErs of those MODULEs at compile
> time. Place that interface information into a separate source which
> must be available to both the MODULE and its USErs at their respective
> compile times. Provided that interface information doesn't change, the
> MODULE and its USErs may be compiled, changed, and/or recompiled in any
> order and the code can simply be relinked. Yes, this *is* what Ada and
> several other languages already do.
>
Yes, it's often (but not always) a good idea to reduce the coupling
between modules, but I don't like the part about manually maintaining
a set of interface statements. Manual duplication of code is a
practice that should be avoided where possible. I guess the next
thing I hear about is a ridiculous workaround-tool for automatic
maintenance of interface blocks --- a command line tool, an INCLUDE
pattern or editor macros.
Fortran has a mechanism for automatic interfaces. That mechanism
is safe and easy to use, thus it should be used. I will believe this
until someone from X3J3 publicly states: "Automatic interfaces
between modules were never intended for large projects."
> As for inlining and aggressive interprocedural analysis, that is an
> issue which *should* be distinct from the MODULE feature.
This is not essential for this discussion (see below), but again, I
disagree. Suppose you have a module, lets make it simple and call it
"math", an utility math library doing simple algebra which is
essential to several of your projects. How can you say that none of
these routines would benefit from inlining?
> To be sure,
> since MODULE code is all grouped together, such aggressive techniques
> should be applied *within* the MODULE. The other place such techniques
> should be routinely applied is for internal procedures. Any procedure
> contained within another should have all such aggressive techniques
> within the skill of the compiler vendor applied to them - both for calls
> from the containing routine as well as calls among themselves. You
> could have a library of routines which are intended to be inlined (or
> otherwise aggressively analyzed) in the form of text files which can be
> INCLUDEd into the source of the procedures which call them.
>
Please get yourself out of the file/module-scope thinking when
defining dependencies! As I wrote earlier: A real good Fortran
compiler should only recompile the necessary *parts* of a module.
This would require a log of all inlining, and if/when you have such
a log, why not use it between modules also.
--
Viggo L. Norum
James Giles
[...]
> > The problem here is that MODULES grouped several distinct useful
> > capabilities into a single feature.
>
> That is not a problem, it sounds very good actually.
It is *always* a bad idea to have multiple capabilities lumped into a
single language feature which prevents the end user from independently
using each of those capabilities. In this case, the end user is the
person who uses Fortran. Such a user often needs to have a library of
routines which share private variables, but *not* at the same time
introduce dependent compilation
[...]
> Yes, it's often (but not always) a good idea to reduce the coupling
> between modules, but I don't like the part about manually maintaining
> a set of interface statements. Manual duplication of code is a
> practice that should be avoided where possible. [...
I don't like manually maintaining redundant information either. That's
why I don't like 'make' at all. Every time I modify a code so that it
calls different externals, I must modify my make files to reflect the
new dependencies. I shouldn't have to do that. That's why I said in my
previous article on this subject that 'make' was itself a workaround.
The problem is that *something* has to express the program's
dependencies. It would be better if you could express them directly in
the program's source. Workable, system independent ways of doing so are
invited.
> ...] I guess the next
> thing I hear about is a ridiculous workaround-tool for automatic
> maintenance of interface blocks --- a command line tool, an INCLUDE
> pattern or editor macros.
You are ridiculing the solution you are supporting. Instrumenting
compilers and/or 'make' to create and maintain complex '.mod' files
containing interface information *is* a ridiculous workaround tool for
automatic maintenence of interface information. It is as complex,
messy, and error prone as the fleet of additional utilities you are
hypothetically supposing (incorrectly) that I support.
[...]
> Fortran has a mechanism for automatic interfaces. That mechanism
> is safe and easy to use, thus it should be used. I will believe this
> until someone from X3J3 publicly states: "Automatic interfaces
> between modules were never intended for large projects."
Ok. I have an alternative proposal. It has the same consequences as my
previous proposal, but requires no duplication of interface
information. The Fortran standard says that the PUBLIC parts of a
MODULE must be available at the time any USE of that MODULE is
processed. Fine. Explicilty state the the *code* of a MODULE procedure
is *not* PUBLIC. Only the interface information is PUBLIC. That way if
you change a MODULE by changing only the code, it should be completely
safe to reload and go - you shouldn't have to recompile any USErs.
Unfortunately, this solution provides no automatic check to insure that
only the code and not the interface has changed. That is, unless the
loader does such checking. The last time I recommended interface
checking be placed into the loader, everyone dismissed the idea.
>
> > As for inlining and aggressive interprocedural analysis, that is an
> > issue which *should* be distinct from the MODULE feature.
>
> This is not essential for this discussion (see below), but again, I
> disagree. Suppose you have a module, lets make it simple and call it
> "math", an utility math library doing simple algebra which is
> essential to several of your projects. How can you say that none of
> these routines would benefit from inlining?
I didn't say they wouldn't. I said that the choice of whether they were
made available to be inlined should be made by the Fortran programmer
and not the standard committee or the compiler vendor. Simply placing
the routines into a MODULE should not automatically mean the compiler is
free to inline them if it pleases. Similarly, routines *not* in MODULEs
should not be prevented from being inlined. The MODULE feature should
be distinct from the capability of inlining.
It should be possible to use MODULE for its primary purpose of scope
control without forcing the user to *always* accept the overhead and
inconvenience of dependent compilation at the same time. So, provide
the user with a way to declare that the code part of the MODULE is
PUBLIC, but make the code PRIVATE by default. That way, if the user
wants to allow the compiler to do aggressive interprocedural analysis
(at the expense of losing independent compilation) it can be permitted
explicitly.
The bottom line in all this is that you've yet to state how all your
automated handling of these features provide the Fortran programmer with
explicit control over when and/or whether recompilation of USEs might be
required. There are instances in which I want to *guarantee* that such
recompilation will not be necessary. At present, the standard *always*
requires recompilation of USE-ing code. So, when independent
compilation is required, I must avoid MODULEs entirely.
Jeffrey Templon
William Clodius <wclo...@lanl.gov> writes:
Hi All,
A couple responses, and a comment:
> standardization committees. Your restriction eliminates de facto
> standardization. I note below that you are working exclusively on UNIX
> workstations. The Fortran standardization committees are not concerned
OK, point well taken. If multiple different methods of doing
auto dependency checks emerge, someone will make a smart enough 'make'
and I can use that, and ignore the multiple methods. If one emerges,
I can use that.
> > Right now I am working on a code which has *many* different modules,
>
> I thought you were working only on F77 code where the concept of module
> is not defined, although sometimes the term module is used as synonymous
We're (or I am) considering to move to F90. Some of you will be aware of
past anti-F90 tirades, but watching the code I'm working on grow and
tangle, I'm becoming convinced it is a good idea to make *some* kind
of move. F90 is the lowest-impact move we can make that will alleviate
the problems I see.
> How does a proprietary interface on one platform hurt you on other
> platforms? What would complicate your life is a reliance on an interface
> that is not available to your users, and does not generate the
> appropriate makefiles. I note that you have sometimes spoken well of
> Eiffel, whose comercial implementations rely extensively on proprietary
> dependency checkers.
The problem is that this code is distributed in source form to users,
who compile it themselves, possibly making some changes to the source.
This is 57,000 lines of source (including comments) so it necessarily
consists of many different files, which I expect will at some point
evolve into module files if the F90 move takes place. [ other possible
candidates, which have their own problems, are Objective-C and Oberon-2 ].
So, I have to make a build procedure which will run correctly
on ALL of the platforms I listed. The only types of autodependency
checks which will help me are:
1) if some process needs to be invoked, but it is the same on every machine,
or
2) it is completely automatic, and can handle several hundred files
as input on the command line (the current count of source + include
files is 433)
Hope this clears things up. As for Eiffel, I should remove my kind
words about it. Tried it in a project. Nice in theory, but in
practice I think the language lacks expressiveness, so that trying
to do anything at all quickly gets you into having lots of classes
flying around.
One point: apparently Oberon-2 does what one of you (Mr. Giles?)
suggested. It keeps something called a _symbol file_ around which
contains the interface of the associated module file. Seems to
work well, and it doubles as input for a class-definition browser
program.
I also agree with whomever it was who said "it's almost always a bad
idea to package several different features into one lump."
JT
James Giles
Jeffrey Templon wrote:
[...]
> I also agree with whomever it was who said "it's almost always a bad
> idea to package several different features into one lump."
I may make the following part of my signature file:
It may seem clever to put a knife and a corkscrew into the
same tool. But how clever would it seem if every time you
want to cut something, you *must* also pull a cork, and
vice-versa?
Van Snyder
In article <33453B...@cris.com>, James Giles <JGi...@cris.com> writes:
|> Viggo Norum wrote:
|> [...]
|> > Fortran has a mechanism for automatic interfaces. That mechanism
|> > is safe and easy to use, thus it should be used. I will believe this
|> > until someone from X3J3 publicly states: "Automatic interfaces
|> > between modules were never intended for large projects."
|> James Giles wrote:
|> Ok. I have an alternative proposal. It has the same consequences as my
|> previous proposal, but requires no duplication of interface
|> information. The Fortran standard says that the PUBLIC parts of a
|> MODULE must be available at the time any USE of that MODULE is
|> processed. Fine. Explicilty state the the *code* of a MODULE procedure
|> is *not* PUBLIC. Only the interface information is PUBLIC. That way if
|> you change a MODULE by changing only the code, it should be completely
|> safe to reload and go - you shouldn't have to recompile any USErs.
|>
|> Unfortunately, this solution provides no automatic check to insure that
|> only the code and not the interface has changed. That is, unless the
|> loader does such checking. The last time I recommended interface
|> checking be placed into the loader, everyone dismissed the idea.
An even better solution would be to separate MODULE into SPECIFICATION
MODULE and IMPLEMENTATION module. The standard _can_ be changed to do
this _without_ breaking existing Fortran 90 code (but it should have
been done in 1986).
As for the linker checking interfaces: At least the consistency of
compilation order can be checked, without changing conventional (brain-
cramped) linkers, by creating bogus external references and definitions
that include date-and-time stamps. Some Modula and Ada compilers do this
already. A similar trick could be used to check type signatures. But I
agree that doing a _real_ job of it in the linker is better. While you're
at it, foist more work onto the linker, like global register allocation.
There've been enough academic papers about how to do it (and a few from
folks at DEC who were doing it with VAX linkers 10-15 years ago). It's
_not_ new technology.
These issues can also be attacked by separating specification and implementation
into two modules: If a procedure body appears in a specification module, the
compiler can inline it. If it's in the implementation module, it can't.
Viggo Norum
James Giles <JGi...@cris.com> writes:
[....]
> It is *always* a bad idea to have multiple capabilities lumped into a
> single language feature which prevents the end user from independently
> using each of those capabilities.
Not *always* a bad idea. (I think you are generalizing too much.)
Dependent compilation is not necessarily *evil*, is it? It just
needs to be handled efficiently, correctly and automatically.
[...]
> The problem is that *something* has to express the program's
> dependencies. It would be better if you could express them directly in
> the program's source. Workable, system independent ways of doing so are
> invited.
Here is how I think it should be. Example:
When the compiler reaches a statement "use A", it should go searching
for "module A" in pre-defined (system dependent) places, on most
systems that would be in .f90 .mod .com and/or .o files in certain
directories. Then it should compile the parts of "module A" which
needs compilation and continue where it found the "use" statement.
All the user should need to do is a system dependent variant of
"f90 mainprog.f90". (System dependent because it may for example be
implemented as a commend line, a Fortran procedure call or a drag/drop.)
> > ...] I guess the next
> > thing I hear about is a ridiculous workaround-tool for automatic
> > maintenance of interface blocks --- a command line tool, an INCLUDE
> > pattern or editor macros.
>
> You are ridiculing the solution you are supporting.
No, I did not. I don't want to see or spend time making those *!一#
extra interface blocks. The compiler should be able to figure it out
without the user or an extra tool as a "hand holding guide".
[...]
> > Fortran has a mechanism for automatic interfaces. That mechanism
> > is safe and easy to use, thus it should be used. I will believe this
> > until someone from X3J3 publicly states: "Automatic interfaces
> > between modules were never intended for large projects."
>
> Ok. I have an alternative proposal.
That proposal appears to be irrelevant for this discussion. If it had
not been rejected 12 years ago, then maybe Fortran modules had been
different, now it's just a "dead horse". I am not trying to change
the Fortran standard, I am just trying to make suggestions on how to
use it better.
[... distinct features <--> distinct control, sniped ...]
You seem to want the programmer to have control over *everything*.
I think it's better to delegate as much as possible to the compiler.
That's one of the reasons why I use Fortran, not assembler or C. The
programmer should have the ability to override the defaults in some
decisions, but not *all*.
> The bottom line in all this is that you've yet to state how all your
> automated handling of these features provide the Fortran programmer with
> explicit control over when and/or whether recompilation of USEs might be
> required. There are instances in which I want to *guarantee* that such
> recompilation will not be necessary.
That's easy when living in the "Utopia" I described, by an example 50
lines above: As long as the source code of an USEd module is
accessible to the compiler, it should check if parts of the module
(note: MODULE, not USE) needs compilation. If you want to *guarantee*
that no part of a module is to be recompiled, then move it's source to
a place where the compiler can not reach it.
> At present, the standard *always*
> requires recompilation of USE-ing code.
No, it only requires a quick check, not always recompilation. By the
way: Does the standard say you can not do it the other way round:
Check if parts of the code inside a USEd MODULE need compilation?
That approach would also (besides enhancing the user interface of the
compiler) open for the use templated types inside modules. Templates
are recognized in other prog.langs. as a tool for making code that is
both flexible and efficient.
--
Viggo L. Norum
Viggo Norum
James Giles <JGi...@cris.com> writes:
>
> It may seem clever to put a knife and a corkscrew into the
> same tool. But how clever would it seem if every time you
> want to cut something, you *must* also pull a cork, and
> vice-versa?
That tool, which cuts the wrapping and pull the cork in one process,
could be a very efficient tool for it's limited use. You don't use a
cork opener when you want to slice something and you don't use
automatic interfaces between modules when you want independent
compilation of Fortran source files.
Also; Fortran modules are often so large that it is inefficient to
compile them in one piece. The whole notion "independent compilation
of files" disappears as soon as you compile only parts of modules.
--
Viggo L. Norum
James Giles
Viggo Norum wrote:
>
> James Giles <JGi...@cris.com> writes:
>
> [....]
> > It is *always* a bad idea to have multiple capabilities lumped into a
> > single language feature which prevents the end user from independently
> > using each of those capabilities.
>
> Not *always* a bad idea. (I think you are generalizing too much.)
> Dependent compilation is not necessarily *evil*, is it? It just
> needs to be handled efficiently, correctly and automatically.
Fine, then when I want explicit, complete, reliable control over when
(and if) dependent compilation will be necessary (that is - always) I
will avoid using MODULEs. Too bad. Some of the other features of
MODULEs are likely to be useful. The lack of explicit control is the
worst of the feature. Dependent compilation might, itself, have uses -
but not if I can't control when (or if) those uses are applied to my
code.
>
> Here is how I think it should be. Example:
>
> When the compiler reaches a statement "use A", it should go searching
> for "module A" in pre-defined (system dependent) places, on most
> systems that would be in .f90 .mod .com and/or .o files in certain
> directories. Then it should compile the parts of "module A" which
> needs compilation and continue where it found the "use" statement.
>
> All the user should need to do is a system dependent variant of
> "f90 mainprog.f90". (System dependent because it may for example be
> implemented as a commend line, a Fortran procedure call or a drag/drop.)
Won't work. Suppose you have already built such a program and you get
an upgrade MODULE from some vendor. Meanwhile you have several other
libraries from other vendors. They are mutually dependent. In the old
days, before MODULEs, you'd just relink and go. Now you have to expend
the additional time to recompile - except you can't. Any library from
an external vendor, for which you don't have source and which depends on
the MODULE that's just been revised, *CAN'T* be reprocessed. It
--->>>*CAN'T*<<<--- be recompiled. Period. So, you can't use the new
verion of the MODULE.
That's only the first problem with you method. Another is that during
code development, the user has more than one version of each MODULE: the
current 'work version' and the more stable 'last release' version (and
maybe more of each). Under your model, each time a code is compiled,
all those "pre-defined (system dependent) places" must be edited before
hand to determine which versions of those modules you want the present
compile to use. The source code contains no directives about versions -
that is the principle reason that 'make' couldn't be done automatically
by the compiler in the first place: no information is present in the
source for the program itself which relates the external objects being
referenced to the file, library, or directory in which the expected
version of those objects are described. This is what I meant before
when I said:
> The problem is that *something* has to express the program's
> dependencies. It would be better if you could express them directly in
> the program's source. Workable, system independent ways of doing so are
> invited.
Since no vendor wants to place his (her) customers into such binds, no
smart vendor (one with enough foresight to see the problems) will
distribute code as MODULEs. This is a stong disincentive. One that
could easily have been avoided if the committee had designed modules so
that altering the body of a piece of code without altering its interface
could be done without requiring the recompilation of all USEs. Few
other languages which support modularization in similar ways require
such recompilation, yet they benefit just as much from the feature. The
Fortran committee should have take a close look at those other languages
- and their rationalization - before adopting a form of the feature
which has such undesirable characteristics. Now, it will certainly be
some time before they fix it and make MODULEs as useful as they ought to
be.
>
> > > ...] I guess the next
> > > thing I hear about is a ridiculous workaround-tool for automatic
> > > maintenance of interface blocks --- a command line tool, an INCLUDE
> > > pattern or editor macros.
> >
> > You are ridiculing the solution you are supporting.
>
> No, I did not. I don't want to see or spend time making those *!一#
> extra interface blocks. The compiler should be able to figure it out
> without the user or an extra tool as a "hand holding guide".
If you can propose a workable, system independent way of doing so, let's
have it. Two properties it *must* have are: explicit control over
whether recompilation of USEs will be required when a MODULE's *code*
(but not its interface) changes; explicit control over which version (of
several possibly present) of a MODULE is to be applied for a given
compile. Other problems due to the lack - in your present proposal - of
explicit user control might be found as well. The main problem is that
it's really hard to anticipate what problems a new restrictive
implementation will cause. Mostly they are only clear in hindsight.
Better not to be restrictive in the first place and leave the user in
explicit control.
[...]
> > Ok. I have an alternative proposal.
>
> That proposal appears to be irrelevant for this discussion. If it had
> not been rejected 12 years ago, then maybe Fortran modules had been
> different, now it's just a "dead horse". I am not trying to change
> the Fortran standard, I am just trying to make suggestions on how to
> use it better.
Well, it's not at all clear that they even considered these issues 12
years ago (much less that they rejected the solution - which can be made
in an upward compatible way even now). Certainly there were no *public*
discussions of this issue at that time (I was watching carefully in
those days - more so than now).
In any case, I *am* trying to change the standard. None of the
suggestions you've made seem to make the present standard any better.
If they were all in place - in all implementations, so that they were
universal - I would still mostly need to avoid MODULEs, and there'd be
several cases when I'd take the plunge and use them only to wish I
hadn't. None of your suggestions even slightly alter this situation.
>
> [... distinct features <--> distinct control, sniped ...]
>
> You seem to want the programmer to have control over *everything*.
The programmer *does* control everything. Anything the vendor doesn't
permit, the end user can get around by switching to another vendor.
Anything the language doesn't permit, the user can get around by
switching to another language (a solution that many F90 features seem
specifically designed to encourage). Even systems and hardware can be
changed. Such changes might be expensive and/or wrenching, but they can
be made. Best not forget that.
> I think it's better to delegate as much as possible to the compiler.
> That's one of the reasons why I use Fortran, not assembler or C. The
> programmer should have the ability to override the defaults in some
> decisions, but not *all*.
I disagree. One of the principle reasons I like Fortran more than C is
that the I have *more* control over my code with Fortran, particularly
with respect to aliasing (the committee seems determined to eliminate
that advantage as well). You are confusing control with abstraction.
Fortran gives a higher level of abstraction (for example: arrays and
character strings instead of raw pointers). Fortran also allows a
greater degree of control over the operation of the program (that I call
its 'pragmatics'). It is the higher level of abstraction which sets
Fortran above assembly. It's both abstraction and control which sets it
above C.
And, I already have control over the issue of independent compilation: I
can compile my code without MODULEs (or perhaps put only INTERFACEs into
MODULEs and separately compile the code). This deprives me of the main
advantage of MODULEs: PRIVATE variables and procedures. But I can
switch to other languages which provide me with *all* of the advantages
of MODULEs without foisting dependent compilation on me. I don't want
to, but I easily could.
>
> > The bottom line in all this is that you've yet to state how all your
> > automated handling of these features provide the Fortran programmer with
> > explicit control over when and/or whether recompilation of USEs might be
> > required. There are instances in which I want to *guarantee* that such
> > recompilation will not be necessary.
>
> That's easy when living in the "Utopia" I described, by an example 50
> lines above: As long as the source code of an USEd module is
> accessible to the compiler, it should check if parts of the module
> (note: MODULE, not USE) needs compilation. If you want to *guarantee*
> that no part of a module is to be recompiled, then move it's source to
> a place where the compiler can not reach it.
I'm not interested (within the scope of this discussion as it has
developed so far) in whether a MODULE needs recompilation when a USE is
processed (indeed, I don't think that's ever the case anyway - if you
have a compiled, up to date version of the MODULE, no variant of USE can
require you to recompile it). I want control over whether a USE of the
module needs recompilation when the MODULE changes. (Yes, such a USE
might occur in yet another MODULE so strictly speaking, I *do* care
about recompiling the MODULEs.) Nothing in your present proposal even
addresses the issue I've continuously raised: can I change the code in a
MODULE and just relink the USEs of it? I want to be able to *guarantee*
that such is possible. I don't want to have to recompile my whole
environment and everything in it every time someone bug-fixes a
low-lying MODULE. It's usually not even possible to do so.
James Giles
> > same tool. But how clever would it seem if every time you
> > want to cut something, you *must* also pull a cork, and
> > vice-versa?
>
> That tool, which cuts the wrapping and pull the cork in one process,
> could be a very efficient tool for it's limited use. You don't use a
> cork opener when you want to slice something and you don't use
> automatic interfaces between modules when you want independent
> compilation of Fortran source files.
I also don't use MODULEs when I want independent compilation even if I
also want several procedures to share PRIVATE data. The reason I don't
use MODULEs then is that the languages provides me *NO* way of doing
so. I want to use the knife, but the language also forces me to contend
with the corkscrew.
>
> Also; Fortran modules are often so large that it is inefficient to
> compile them in one piece. The whole notion "independent compilation
> of files" disappears as soon as you compile only parts of modules.
If recompilation is so expensive, then forcing *all* USEs of a MODULE to
be recompiled when a MODULE changes must really be costly. Best to
avoid MODULEs so that you need only to relink. Too bad about the lack -
in this case - of PRIVATE data and procedures. That always seemed the
main (possibly the only) advanage of MODULEs. Can't use it though, it
forces dependent compilation.
Jeffrey Templon
Hi,
I think I'm missing something. People are talking about all the hassle
of maintaining the interface blocks. Why not have the compiler do
that??
I like the way Oberon-2 does it. When a module is compiled, an object
and a symbol file are produced. The symbol file contains the (public)
interface to the object. Recompilation of a module does not change
its interface block (symbol file) unless the interface does change.
In fact, you have to supply a special switch to the compiler to
allow interface changes; otherwise, you get a warning.
Some compilers go one step further -- they allow _extension_ of
the interface, i.e. nothing existing is changed, only addition.
These compilers are smart enough to know that they don't have
to recompile other modules if they only depend on the part of
the interface that was not changed.
The reason they did it this way in Oberon-2 is precisely to address
the criticism mentioned here (Mr. Norum?) -- it was way too error
prone to have to separately maintain an interface block (symbol file)
AND the interface in the source code.
Another point: by making the symbol file part of the language specification,
one guarantees that on any Oberon system, this file exists and can be
used as input file for a class browser. This is then a simple tool
since it doesn't have to figure out from the source what the interface
is.
Why not something like that?
JT
Lucio Chiappetti
On Thu, 3 Apr 1997, James Giles wrote:
> Note also that INCLUDE and USE have completely different effects. I
> have never been among those who believed that INCLUDE was redundant. It
> does something completely distinct from MODULE/USE - as this example
> clearly demonstrates. Having said that, INCLUDE *is* redundant with any
> good text editor. Macros which perform INCLUDE should be easy to write
> in any modern editor. So, if the committee chooses to delete INCLUDE in
> some future standard, they're certainly wrong, but who cares?
Can anybody enlighten me in a few words about what a MODULE really is ?
I read about them in a book about Fortran 90 and could not understand
clearly what they were, it seemed to imply references solved at linkage
time more than compilation time. I had a lot of f77 stuff, and this did
not encourage me to do the move to f90.
I use INCLUDE in f77 a lot.
I put there things like COMMON block declarations, or lists of PARAMETER
declarations (from error codes to standard constants like pi or the radians to
degree conversion). Occasionally during development I put there a subroutine
which is called by a couple of programs and which I do not want to put in a
ranlib library until I've debugged it.
Obviously particularly for the COMMON blocks I want to be sure that all
programs which refer to them are recompiled when the layout of the common is
modified. How can an editor do it ?
And how can a compiler do it in a portable way with a supposed module, if it
is referred to with a single name, and is "called" from several routines in
different libraries ?
(this is true also of INCLUDEs, they refer to filenames and paths are not
portable, eg. Unix vs VMS, so I solved this using only pathless lowercase
names, putting all include files in a separate subdirectory, and having a
wrapper around the compilation command to take appropriate actions, from an
appropriate compiler option to making soft link of all files in a scratch
directory and compile there)
----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)
----------------------------------------------------------------------------
Fuscim donca de Miragn E tornem a sta scio' in Bregn
Che i fachign e i cortesagn Magl' insema no stagn begn
Drizza la', compa' Tapogn (Rabisch, II 41, 96-99)
----------------------------------------------------------------------------
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html
----------------------------------------------------------------------------