James Giles wrote:
>
> From: Lionel, Steven <[log in to unmask]> :
> ...
> >When you have a module which uses another module, all of the symbols from
> >the USEd module are exported by the outer module. When you have lots of
> >these, and a program unit which USEs several/many of these modules, the
> >compiler needs to resolve hundreds or thousands of duplicate names, to make
> >sure that there are no conflicts or to see that the duplicates are really
> >the same original declaration (and haven't been renamed or had accessibility
> >changes). This takes a lot of CPU time and a lot of virtual memory.
>
> That's an interesting description. I would have assumed (this is the way
> I'd have tried to implement it) that a module would export only the names
> of the objects it declares itself and the names of the modules it used, not
> the names of all the objects within those other modules. For example:
>
> Module A
> ... some stuff ...
> End Module A
>
> Module B
> Use A
> ... some stuff ...
> End Module B
>
> Program Test
> Use A
> Use B
> ...
> End Program Test
>
> In this instance, when the main program is compiled the compiler need
> only notice that module A has been used twice: once directly and once
> through module B. It need not wade through all of the elements of
> A twice to make sure that they are valid.
>
> Is there some specific reason this method was not chosen?
Probably because modules can be awful complicated if the ONLY and
RENAME features are used. Something like
use A, only : xx => x
use A, only : yy => x
use A
brings in 3 names for "x" (and maybe lots of other stuff)
or
use A, only : x
use B, only : x
is legal (but in poor taste) and disallows any reference
to "x". It's worse if some of the USE statements are not in the
subprogram being compiled, but are up the module reference tree.
Every module that uses A has the potential to rename x or to
make it unusable.
Dick Hendrickson
>
> --
> J. Giles
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|