.mod file compatibility

[Janne Blomqvist]

On Sat, Sep 7, 2013 at 4:09 AM, W Spector <w6ws@earthlink.net> wrote:
> I fully appreciate the desire to bump the .mod version when the ABI changes
> to better support some feature.  But it seems like there are often ways the
> incompatiblity could be managed such that only codes which actually used
> area where the ABI was changed need to be recompiled.

Yes, there are ways, but who's signing up to actually do it? I'm not
very hopeful that this can be done in a reasonable fashion with the
current module implementation in gfortran, and if so, designing and
implementing a new module implementation is a lot of work. Currently a
module is more like a brain dump of (a subset of) the compiler
internal data structures, and thus it seems to me very difficult to
isolate changes in the compiler internals from affecting the module
format. Even comparatively simple things like reordering the way
sections in a module file are parsed leads to infuriating whack-a-mole
games making you wish you'd rather be at the dentist having your teeth
drilled (speaking from personal experience). ;-/

I think a serious shot at module file compatibility would require
something along

- A separate internal representation for modules. That is, to separate
reading and parsing a module from importing symbols and stuff into the
current namespace. This would also allow other occasionally discussed
nice-to-have features such as a module cache.

- Separate version numbers for module file sections (or maybe even
more fine-grained), instead of a single version for the entire module.
This way e.g. a change in some of the F2003 OOP stuff shouldn't affect
the basic F90 stuff, and implementing backwards-compatibility could
maybe be done in an incremental fashion where possible with a
reasonable effort.


-- 
Janne Blomqvist