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

[Zoltan Somogyi]

On Tue, 17 Nov 2015 14:05:22 +1100, Paul Bone <paul at bone.id.au> 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.

I think there are two ways to do a transition.

The first is to introduce a new compiler option, say --no-imports-in-int0,
which would tell the compiler not to put import_module declarations
into .int0 files. You could then ask people to turn it on, and after a
transition period make it the default, requiring people to specify
--imports-in-int0 to get the old behavior. After a further transition
period, you could then delete the option, making the old behavior
unavailable.

The second is to start directly with the compiler not putting import_module
declarations into .int0 files unless the programmer specifies --imports-in-int0.

The second has a higher probability of giving people a surprise, but the
action they need to take to resolve the surprise (code that used to compile
now not compiling due to missing imports) is just the specification of an
option, and we could modify the error message we generate for errors
that can arise from missing imports to mention the --imports-in-int0 option.
(If anyone has a better name in mind, please speak up.)

The good thing is that the implementation of both approaches is
the same, modulo the default setting of the option.

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

But what part of package A are you using? Yes you are using A.B, but
are you using any other parts of A? If yes, you should import A; if not,
you shouldn't have to.

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

Why should people have to do that?

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

That seems to be the consensus. If anyone objects, please speak up now.

Zoltan.