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

[Mark Brown]

On Thu, Nov 12, 2015 at 7:17 PM, Zoltan Somogyi
<zoltan.somogyi at runbox.com> wrote:
> On Thu, 12 Nov 2015 01:40:49 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> 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?

With a suitable transition period, I would support changing the rules
so that they are not available at all.

>
> While doing the above diff, I wondered about *why* the compiler
> says that a module C importing module A.B is required to import
> module A as well. What I could find in the log messages is that
> we need to ensure that module A actually contains an include_module
> declaration for A.B. That is a valid reason, but I don't think it justifies
> making everything in the interface of A available to C; I think it just
> means that when compiling C, we should check A's interface
> to see if it contains an include_module for A.B. That can be done
> without a full import.
>
> Does anyone know of any other reason why we require an import
> of A to be available to module C if module C imports A.B? I don't,
> and as far as I can tell, the reference manual doesn't say; in fact,
> I couldn't even find any mention of the requirement itself.
>
> If noone knows of any other reason, I propose we change the de-facto
> rules to NOT require the import of A into C when C imports A.B,
> but to implement only the "does A include B?" check mentioned above.
> Unfortunately, we would still have to read A's interface for that check,
> but it should be sufficient to read A.int3, not A.int. Since .int3 files
> change less frequently than .int files, this should still allow us to avoid
> a lot of unnecessary recompilations when new modules are added.
>
> For all I know, this may have been Fergus's intention when he
> implemented submodules, but implementing this check without
> actually doing an import may have been too hard with the
> old item list program representation :-(

My recollection is that Fergus intended it the way it currently is but
he was deliberately being conservative, meaning it could be relaxed
once people had more experience with it. I'd be happy removing the
requirement to import the parent in order to import the child, with no
transition period.

Mark