Jean Vezina wrote:
> 
> Swietanowski Artur wrote:
> >
> > Dear All,
> >
> > I've spent most of the day today coding in F90 and I got frustrated
> > again with inflexibility of modules.
> >
> > As it was mentioned / discussed quite a few times ago, F90 modules
> > do not support separation of interface and implementation. It might
> > seem like a rather abstract pseudo-problem for some of the members
> > of the group but it has some easily understandable negative
> > consequences.
> >
> > To recall them:
> > a) it is not possible to provide modularly desiged libraries in
> >    form other than source (not an option for many (most?) software
> >    writers),
> 
> This is not true, at least not for Digital Fortran and a couple of
> other compilers. All you have to do is to distribute the object (*.obj)
> or library (*.lib) with their associated *.mod and *.m files. I
> am regularly doing this and the Fortran 90 version of IMSL is
> distributed that way (for Digital Visual Fortran again). If your
> compiler doesn't allow you to do this, complain to your vendor.

I think it miss the point!  Yes, you can, because your modules do not
use my modules.  However, I can not, because my modules have to use
your binary *.mod files to compile.  To make sure my binaries are 
up to date, I have to wait until your latest version *.mod release 
becomes available, to recompile all my binaries for my release.  For 
a large system, this sequential build paradigm is obviously not 
acceptable.  Therefore, source releases become the only option (let
the builder to worry about it).

Apparently, loaders on some systems do not check the consistency of 
the actual modules are the same as the modules USEd at the compilation 
time.  As long as the names of the module, the type, and the module
procedures are the same, details are not checked.  Therefore, I may 
build my binaries based on YOUR (why?  Interface should be mutually!) 
previous release of *.mod.  I guess it would make loose the sequential 
contraint.  However, it also creates a perfect loophole in using 
modules, since at the meantime, you are not restricted (actually you 
can not) in anyway to build your binaries based on the same *.mod 
release that we both agreed upon.

> 
> > b) changes in implementation part of the module require (otherwise
> >    unnecessary) recompilation of all dependent source files,
> 
> This is an implementation issue.
> 
> This problem could be solved if compilers write the *.mod file first
> into a temporary file, then check after if differences are present
> by comparing with the original *.mod , and leaving this file intact
> if no changes are present. Implementing this should not be more complex
> than the existing code optimization technologies.  In the last months,
> there was a considerable debate around this point in comp-fortran-90 and
> it is probable that the major F90 compiler suppliers are already working
> on a solution.

If I release binaries, MY compiler (or make) really should not care 
if YOUR compiler has recreated/restamped the *.mod file.  I can only 
assume a) your *.mod files are the same ones I used; or b) your 
compiler has warned you that your new *.mod are not the same *.mod
we have agreed upon.  Therefore, your compiler should never give the
power to impose the new interface (unless it is the year 2001 :-)).

Jing
-- 
________________________________ _-__-_-_ _-___---
Jing Guo, [log in to unmask], (301)805-8333(o), (301)805-7960(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771


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