[m-dev.] .int0 files and solver types -- interface_files.html

[Julien Fischer]

Hi Zoltan,

On Sun, 30 Jun 2019, Zoltan Somogyi wrote:

> I just had a look at the submodules/ts test case. The cause of the problem that leads
> to failure in the presence of intermodule optimization is that when compiling ts.tsub.m,
> the compiler gets two copies of the solver type definition in ts.m: from ts.int0, and from ts.opt.
>
> The comment in ts.m says the problem is the presence of the definition in ts.int0.
> I disagree: I think the problem is the presence of the definition in ts.opt. I think this
> because all the interface files in that program look exactly the same with and without
> intermodule optimization, which is the proper state of affairs.

I'm pretty sure I wrote that comment and it probably refers to the fact
that at the time the error was reported as originating in the private
interface.

> I think the root cause is likely to be that noone ever sat down and designed what
> the interaction of intermodule optimization and submodules ought to be. The basic
> question that I don't think we have ever even tried to answer is: is module A's
> .opt file supposed to be read by module A's submodules?

That's definitely true for the case of mutables and solver_types.
(Their original author never tested them with --intermodule-optimization
before committing them.)

> At the moment, the answer (arrived at by default) is "yes". This immediately causes
> our problem, because both .int0 files and .opt files contain information from a module's
> implementation section. They typically contain different subsets of that information,
> but those subsets can, and sometimes do, overlap, and these overlaps by definition
> will result in the things in the overlap being defined twice.
>
> Changing the answer to "no" would work, but would leave optimization opportunities
> unexploited.

The answer should definitely be "yes".

> One possible answer is to generate .int0 and .opt files as before, but, when reading
> in an ancestor's .opt file, effectively doing a diff between that file and the ancestor's
> .int0 file (modulo contexts and the like), and processing only the items that exist
> only in the .opt file. Alternatively, we could set a flag that says "this item came from
> the .opt file of an ancestor, please ignore any  redefinition errors". Overall, I prefer
> the first solution, as it is more precise, and has no distributed fat.
>
> What are your opinions about all this?

I prefer the first solution as well.

Julien.