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

[Paul Bone]

On Tue, Nov 17, 2015 at 04:52:25PM +1100, Zoltan Somogyi wrote:
> 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.

I don't mind either of these.  I think we'll surprise (some) people either
way.

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

This makes sense.  I think it depends on exactly what A is.  And therefore
people shouldn't be forced to import A to use A.B.

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

They shouldn't have to.  I was in the practice of doing this because of how
visibility works in Mercury, I did it to reduce incidental coupling.


-- 
Paul Bone