Hi,

On Wed, 12 Jun 2002, Van Snyder ([log in to unmask]) wrote:

> I did, and complained several times, both during the latter stages of
> development and during public comment.  I was not serving on X3J3 at the
> time, so I cannot speculate why the problem was not corrected before
> Fortran 90 was published.

I'm glad I'm not the only one frustrated by all of this.

At the moment I'm optimising PRIVATE routines of a particular module.
This module only takes a minute to compile, but the one that USEs it takes
about ten minutes to compile.  Linking takes about a minute.  The test job
that I run to make sure I haven't stuffed up (eg, typos) takes only 25
seconds to run.  Avoiding the cascade is a *big* issue for me :).

> It has now been realized that there are problems, and a Type-II Technical
> Report has been authorized to address the deficiencies.  The subject of
> the report is to allow expressing a module as an "interface" part and
> zero or more "implementation" parts, as is done in Modula-2 (only one
> implementation part) and Ada (multiple implementation parts by way of
> "library subunits").  The "interface" part will be compatible with
> Fortran 2000 modules.  I.e., you can put everything there, and have no
> "implementation" parts.  The "implementation" parts for a single module
> will depend on its "interface" part, not vice-versa, and perhaps on each
> other.  Nothing else can depend on them, so you can change a detail of an
> "implementation" part of a module, and not get a compilation cascade.
> More importantly, if your software engineering protocol requires
> re-certification of every program unit that gets re-compiled, you don't
> get a re-certification cascade, which could be far more expensive than a
> compilation cascade.

I really like the sound of this.  I don't mind additional files generated
by the compiler hanging around that contain "implementation" stuff if
they need it, but it would be great to *require* .mod files contain only
"interface" stuff.  It wouldn't fully address the problems of having files
up to date (still have to use timestamp files, recursive Make, checksums,
or ...), but it would absolutely minimise the cascade and make our silly
"cmp" scripts redundant.

> A Type-II Technical Report has nearly the stature of a standard.  The
> agreement is that it will be incorporated into the next standard
> exactly as specified, unless substantial implementation problems or usage
> problems are discovered.  There have already been two Type-II Technical
> Reports that amend Fortran 95.  Many vendors have implemented them, and
> they are being incorporated into the Fortran 2000 standard.
> The plan is that the technical report on module facilities will be
> published at about the same time as the standard.

Will the report be published separately?  It would be great to have part
of it in section C.8.2 of the standard, i.e., say that module information
files contain interface information only.

While we're at it, I think a slight modification to C.8.2.1 of the
standard would go a long way to universal makefiles/scripts.  For example,
in regard to module information files, "Thus the processor may have to
provide a mapping between Fortran name and system names" is a bit vague,
as there's nothing about file extensions or uppercase/lowercase.  Whilst
MS-DOS can't handle names more than 8 characters long, it seems that
all(?) O/S's can handle a .mod suffix, so it would not be difficult to
force the generation of a .mod file with interface-only information.
Likewise, most Unices can handle uppercase and lowercase, yet the vendors
are split down the middle as to who uses uppercase and who uses lowercase.
MS-DOS has it's limits, but does this have to translate into ambiguity for
the rest?  (Note that just because a compiler is forced to generate a
certain file doesn't necessarily mean it has to use that file, so
compilers don't need to be rewritten to achieve this.).

Section C.8.2.1 also mentions that .mod files that propogate PUBLIC
information may have pointers to other .mod files rather than just copying
the PUBLIC information into their own .mod files.  I don't think that any
vendors use these pointers, so now is a good time to get rid of the
suggestion.  Such a method makes a meal out of the avoidance of cascading
recompilation, because not only do you have to examine the modules that
you USE, but also the ones that they USE, and so on.  But of course this
is only true for PUBLIC information, not PRIVATE information, so your
dependency generator would have to keep track of PUBLIC and PRIVATE
entities in all prerequisites.  Aargh! Let's get rid of it, and make
"including copies of information originally specified in other modules"
the only option.

F2k is a good opportunity to fix up modules, and this interface-only
requirement sounds like a good idea.  I hope we can fix up these other
smaller problems too.

Regards,
Daniel.

--------------------------------------------------------------------------
Daniel Grimwood                       Department of Chemistry
Email : [log in to unmask]     The University of Western Australia
Phone : +61 8 93803138                35 Stirling Highway
Fax   : +61 8 93801005                Crawley WA 6009