Re: Problem with procedure pointers

[Tobias Burnus <burnus at net-b dot de>]

On 03/10/2011 06:46 PM, Paul Richard Thomas wrote:
> > Side remark: I had hoped that .mod files could be kept compatible between
> > different minor [...] versions
> We should give that some thought.  I am surprised that it is not
> possible since we are adding features in later versions.  We need to
> add a default for missing defaults, for example.

Well, for new attributes (like the proc-pointer components attribute or 
F2008's contiguous), it works fine. However, new features such as 
submodules (which we do not have yet), type extension, etc. it does not. 
At least we keep adding new items in a way that they break reading an 
old .mod file in a new compiler. [Additionally, the opposite can happen: 
One uses an old compiler, which does not understand a new file.]

I think we should consider to revamp the .mod format - completely 
different or only small modifications. I think the following features 
would be useful, though I am not sure in how far they are implementable:

- better backward compatibility
- Smaller file size; printing the attributes in full length creates 
rather huge files. (A zlib compression might be also an option; 
currently the files are 7bit text files, working with all kind of 
encodings and line endings.)
- Optionally: Instead of embedding the information of use-associated 
symbols, refer to those modules. (That's what NAG does; it should be 
optional, however, as if one passes on .mod files, it is helpful that 
one does not need to pass on the whole tree of .mod files)
- Faster reading: That probably means binary, which clashes with 
"backward compatibility".

Maybe the backward compatibility would be possible for some of the older 
features and has just not been implemented as the finer points of how 
gfortran stores data in .mod is not really clear to all developers. (For 
instance, I do have problems with the fine points.)

Before setting a new format into stone, one should make sure that it is 
capable to store all F2008 plus known TR. (As far as it is possible 
without actually implementing those features.)

Tobias

PS: Talking about .mod files: Cray (by default) does not have .mod files 
but stores the data seemingly in the .o file, which is elegant, but 
means that the compiler has to scan through all .o files in the current 
directory to find the module ...