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

[Paul Bone]

On Thu, Nov 12, 2015 at 08:37:21PM +1100, Mark Brown wrote:
> 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.

I think this would be a good change.  I also think there should be a
transition period for this.  How that should be done I don't know.

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

It kind-of made sense to me that if I wanted B which was within the package
A.  Then I should say that I'm using the package A.  Therefore when I write
parent and child modules I try to put as little code, or only common
definitions, in the parent module as possible.

But I don't see any practical reason to keep this rule.  This can be changed
without a transition perioud.


-- 
Paul Bone