[m-rev.] should we break up module_qual.m

[Zoltan Somogyi]

On Wed, 11 Nov 2015 19:56:37 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > Would anyone object to this?
> 
> I have no objections.

OK. Done.

When creating submodules of an existing module,
it always strikes me as weird that the new submodule
needs to import almost nothing, because it inherits most
of the imports it needs from its ancestor modules.
It is weird both because it is different from the usual
experience of working on a module, and because it
effectively couples the submodule to the ancestor modules
(typically, mainly just the parent) in this respect.

At the moment, we assume (in module_qual.qualify_items.m,
in module_qualify_items_in_src_item_blocks, that nothing
that a parent module imports is unused, because a child
module may use it. The code that does it is this:

    (
        Incls = []
    ;
        Incls = [_ | _],
        % The submodule might make use of *any* of the imported modules.
        % There is no way for us to tell which ones. So we conservatively
        % assume that it uses *all* of them.
        % XXX ITEM_LIST Fix this too-conservative behavior.
        % If a submodule needs a module that the parent doesn't,
        % it should import it for itself. Anything else may lead to
        % unnecessary recompilations.
        map.init(UnusedModules),
        mq_info_set_as_yet_unused_interface_modules(UnusedModules, !Info)
    ),

I would like to propose that we eliminate this assumption,
and just delete this code. Having to have N children import
a module instead just one parent may be a bit of extra work,
but the time lost this way will be paid back many times over
if some child does not need an import, since that child then
won't be unnecessarily recompiled when the module imported
changes its interface. Effectively, the cost does not grow
with project lifetime, while the benefit does.

We should also consider changing the rules of inheritance
between parent and child module so that the parent's imports
are not made available to the child module automatically.
We could simply not make them available at all, or we could
make available only the imports that define entities (types,
insts etc) that are needed to make sense of the other things
(e.g. predicate declarations) in the implementation of the parent
that the child gets access to via the parent's .int0 file.

What do people think?

Zoltan.