Base new module format on XML - RFC and some questions

[Tobias Schlüter]

Salvatore Filippone wrote:
> Jerry DeLisle wrote: 
>> c. Bloat reduction:
>         >c1: Do not include USEd modules. Instead use the XInclude facility to
>         >do that. Think "pointer to other module file" (OTOH this makes it
>         >necessary to determine the top-level module(s) of all USEd modules and
>         >only parse that one - bit tricky)
>> I don't quite understand what you are saying above. We don't "include",
>> we "use" Or, are you referring to a syntax that transparently opens and
>> accesses files "behind the scenes" so to speak? Or you refeering to
>> some sort of abstraction layer? I am just not familiar with what
>> XInclude is.
> 
> I think Dennis is referring to a phenomenon that I hinted at during the
> IRC meeting. 
> When you have a module A that USEs another one B, what happens in
> the .mod file? 
> You have basically two alternatives: 
> 1. Include a copy of B.mod inside A.mod
> 2. Just put a directive in A.mod pointing to B.mod
> 
> Solution number 1 means that any code that USEs A only needs access to
> the A.mod file, solution 2 requires access to both .mod files; in this
> respect, 1 is better. Different compilers go for different strategies;
> if I remember correctly, I found that Intel (at least in one of the
> older versions) was for 2, XLF is 1, NAG is 2. 

An alternative approach would be to have one .mod file per source file. 
  Of course then one would need a lookup strategy to find the module 
information when compiling another source file (say, have dummy .mod 
files pointing to the correct source file, or put everything into an 
sqlite database, ...).

It would certainly be helpful to write every USEd thing only once per 
.mod file, even if that doesn't solve all redundancies.

> When you have a complex inheritance hierarchy, things can compound
> spectacularly.
> Consider the total size  in bytes of the .mod files for the F95 version
> of my library:
>   Intel     GNU 46            Nag
> 4090544    6883556         447891
> 
> And if you look at the F03 version:
>             GNU 46            Nag
>          120325072         590488 

Heh, at least there actually is space for improvement ;)  That's how GNU 
attracts contributors ;)

Cheers,
- Tobi

-- 
Tobias Schlüter
Am Coulombwall 1, Zi. 326
85748 Garching b. München
Tel.: +49/89/289-14139