[m-rev.] a question about accessibility rules and error messages

[Peter Wang]

On Wed, 20 Mar 2019 16:53:22 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> I can fix  this one of two ways. One way is to fix the enforcement;
> base the check on the contents of the source file only. In fact, the
> check should to be done twice, once for the interface and once for
> the implementation, because if w.m imports x.y.z in the interface,
> it should import x and x.y in the interface as well. (The reverse is
> not true; if w.m imports x.y.z in the implementation section, it does not
> matter in which section it imports x.y.)
> 
> The other way is to drop the requirement for the *explicit* inclusion
> of ancestor modules, and make the compiler import them implicitly.
> 
> The second approach has the benefit of requiring less typing.
> The first approach has the benefit that it is more canonical:
> given a set of module imports, there is only one way to make that set
> ancestor-complete (i.e. to ensure that for every imported module,
> all its ancestors are imported as well), and the first approach requires it,
> while the second approach permits non-ancestor-complete sets of imports,
> of which there are many.
> 
> I have a slight preference for the first fix, but could easily live with the second.

The first fix is my preference as well as it is a simpler rule.

> If we choose the first fix, then I would propose a change in the diagnostic
> we generate for violations. At the moment, we generate a message of
> this form for every import of a module that is inaccessible:
> 
>   very_long_name.m:123: In module `very_long_name':
>   very_long_name.m:123:   error in `import_module' declaration:
>   very_long_name.m:123:   module `parent_module.sub_module' is inaccessible.
> 
> This means that if e.g. you import ten submodules of the parse_tree package,
> you will get ten such messages, even though there is only one bug: the
> absence of an import of parse_tree itself. I propose to change things
> so that instead of generating one message per *inaccessible* module import,
> we generate one message per *missing* module import. The message would
> of course list the currently-inaccessible modules that the absence of
> this import *makes* inaccessible.

That would be good (though I don't recall being bothered by it myself).

Peter