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

[Zoltan Somogyi]

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

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.

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?

Zoltan.