On Fri, 21 Nov 1997, Van Snyder wrote:

> To put readers in context, in the .M scheme, the base name of the file
> that contains the "data base" that results from compiling the
> specification part of a module is the name of the file containing the
> module, while in the .mod scheme, the base name is the name of the module.
>
> This question and many others would be moot if the specification and
> implementation were separated at the source level. Ada compiler producers
> have discovered that their compilers are just as fast if they just read
> the source form of the package specification, instead of compiling it
> and putting the result in a file analogous to a .M or .mod file. Fortran
> compilers can't do this because specification and implementation are
> lumped together in a single file. Well, they _could_ but it would be
> _really_slow_.
>
> <snip>
>
> The advantage of the .M scheme is that it allows an easier way to write
> make files if you put many modules in one file.
>
> The advantage of the .mod scheme is that the compiler has an easier time
> to find the file containing the "data base" that resulted from compiling
> a module.
>
> Myself, I put modules one-per-file, and use the same file and module
> names, so the methods are equivalent.
>
> <snip>

Thinking about it I have come to like to .M scheme more and more WITHIN
the constraints of current F90/95/2000 standards (or drafts). And
it would to some extent lessen the compilation cascade,
i.e. recompiling many dependent routines that USE a module though the
used module's interface has not changed.
My idea is a bit clumsy but could do the job.
USEing a module makes another routine dependent on the used Module's
interface but not its object file (.o). In the .M scheme one can do
the following:
  compile the file with one or more modules
  compare the new .M with the old .M file
if different replace (.M has new timestamp,
the interface has changed)
          else leave old .M file with old timestamp
  <file>.f90 depends on <others>.M, and of course, on its own <file>.o

This should work quite well with makefiles. There is some extra
work for compiler writers, viz. comparing files and having a fast
way of finding where the "data base" is located but setting up
a hash table for this purpose (or a library) shouldn't be difficult.

Since I also try to put one module per file with the same name
(it doesn't work always) hardly any effort is necessary to go
to the .M scheme. (Just update makemake.perl which I use)

It would be nice if compiler writers could agree on something like this
or even WG5/J3 could 'recommend' a way to provide some unity among
compilers though it is not part of their realm.

WWS
-----------------------------------------------------------------------
| Werner W Schulz |
| Dept of Chemistry email: [log in to unmask] |
| University of Cambridge Phone: (+44) (0)1223 336 502 |
| Lensfield Road Secretary: 1223 336 338 |
| Cambridge CB2 1EW Fax: 1223 336 536 |
| United Kingdom WWW: |
-----------------------------------------------------------------------



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%