Re: Base new module format on XML - RFC and some questions

[Salvatore Filippone <salvatore dot filippone at uniroma2 dot it>]

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. 
 
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 

Now, because of the copying feature, in the current GNU implementation I
can get away with making accessible only a subset of those modules, for
a total of about 10 MB instead of 120, but during the build phase the
GNU compiler is still pushing around all those bytes.
So, this is one of those cases where you have a trade-off between
memory/disk and time. I would think that more feedback is required
before deciding (the golden rule is make the common case fast, and the
rare case correct); I don't particularly care whether the final format
is XML or something else, after all I am not supposed to read it, the
compiler is.  
Anyway, the Nag module files are plain text, they are quite readable,
and still small. 

Hope this helps
Salvatore