[m-rev.] for review: --warn-include-and-non-include

[Zoltan Somogyi]

On Sat, 26 Jul 2025 17:06:36 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> On Sat, 26 Jul 2025 at 05:16, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> > Add a new option, --warn-include-non-include.
> >
> > When enabled, the compiler emits a warning for modules that contain
> > both include_module declarations, and other constructs. In other words,
> > it warns about modules that include submodules but are not "packages".
> 
> Is that restricted to exported submodules or does it apply all submodules, both
> exported and private?  It is not uncommon for non-package modules to delegate
> much of their implementation to private submodules.

You get the warning if

- the module contains one or more include_module declarations,
  it does not matter in which section, and

- the module contains any other declaration or definition, and again
  it does not matter in which section.

I thought that simply not mentioning sections made this clear.
What caused you to consider that sections may matter?
And do you have a proposal for new wording that would
eliminate that uncertainty for you?

> That's one form of "package". The other would be a module that just consists
> of import_module declarations (i.e. to group a bunch of modules together into
> a library).

And a third form would be the things that DHL, Fedex, AusPost etc deliver.
And a fourth would be a set of sanctions imposed on Russia at the same time,
And a fifh ...

Of course, executing and running a program do not involve lethal injections or
legs either, so adding new meanings for existing words has been a tradition
in computing for a long time.

I could delete the clause about such modules being called packages,
but I don't see how depriving the reader of a handy shorthand name
for this class of modules would help.

> I'm not sure how useful this warning is going to be in practice. Thinking about
> much of the code I work with I think there is a conflict between minimising
> recompilations vs. additional complexity in an API due to users having to deal
> with more submodules.

I don't think that having to import e.g. both mdbcomp.feedback and
mdcomp.feedback.feedback_info is at all hard, *if* you control both
the package and its customers. Any difficulty comes in when you do not
control the customers, as is the case e.g. for io.m. Once you have many people
using one set of fully qualified names for some entity, it is not nice to force them
to change to another set. The point of this option is NOT to point out places
that should be changed (as the commented-out code in library/Mmakefile
turning this option OFF should make clear), but to give people who first mix
include_module declarations with other constructs in a module a warning
about the future cost of their possibly-illconsidered decision.

In other words, this is intended not so much to REDUCE the number of modules that
mix include_modules with other code, but rather to stop that number from GROWING.

> That said, the diff looks fine and I have no objections to it being committed.

Thank you.

Zoltan.