[m-rev.] for review: unexported types/insts/modes in interfaces

[Zoltan Somogyi]

On Wed, 11 Nov 2015 14:00:06 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> Or they may be implicitly imported from an ancestor module of A. 

Yes. I noted that in the documentation; I will note it in the
log message as well.

> A related
> question: is the following supposed to be allowed?
> 
>      :- module foo.
>      :- interface.
> 
>          :- module bar.
>          :- interface.
>          :- type bar_t ---> bar_t(foo_t).
>          :- end_module bar.
> 
>      :- implementation.
> 
>      :- type foo_t ---> foo_t.
> 
>      :- end_module foo.
> 
> The current submodule visibility rules say yes, but letting foo_t/0 escape from
> the implementation section of the module foo seems a bit odd.  (Granted, there's
> not much any module that imports foo.bar will be able to do with it.)

At the moment, yes it is allowed, but you are right, we should revisit
that design decision. For the time being, probably 99% of the modules
that import foo.bar will be other submodules of foo, and they have
access to foo_t anyway, so I don't think it is urgent.

> I think we should add a new section to the top of the NEWS file and shift all
> of the changes that are potentially going to "break" existing programs (i.e.
> programs that compiled with Mercury 14.01.X) to there.  For the next release,
> there are a number of such changes.

OK, I will move this announcement there. You should move the others
there.

Thanks for the review.

Zoltan.