[m-dev.] equivalence types, indirect dependencies, and recompilation

[Fergus Henderson]

Suppose you have a module m1, and another module m2 which whose
interface uses m1, and a third module m3 which m2.  Presuming
intermodule optimization is *not* enabled, should m3 need to be
compiled if m1 changes?

In our current implementation, the answer to that is yes.
But I'm thinking that our current implementation may be wrong.
Our current implementation has some definite known bugs with respect
to indirect imports.  I'm not sure whether this one should also
be classified as a bug or not.

Consider, in particular, the following example.
Suppose module m1 contains an equivalence type,

	:- module m1.
	:- interface.
	:- type t == int.

and m2 uses that type,

	:- module m2.
	:- interface.
	:- import_module m1.
	:- func foo == t.

and m3, which uses m2,

	:- module m3.
	:- interface.
	:- import_module io.

	:- pred main(io__state::di, io__state::uo) is det.

	:- implementation
	:- import_module m2.

	main --> { Foo = foo }, print(Foo).

defines a variable `Foo' whose type is m1__t, i.e. int.
Should `m3' need to be recompiled if `m1__t' changes?

In our current implementation, the `.int2' files contain
definitions of any equivalence types such as `m1__t',
and the compiler reads in the `.int2' files for indirectly
imported modules.  This allows it to figure out that `m1__t'
is `int' and thus pass the right type_ctor_info to io__print//1.
But it also means that module `m3' needs to be recompiled
if `m1' changes, even if module `m2' changes, and even though
module `m3' doesn't (directly) import module `m1'.

This issue is similar to the issue with abstract equivalence types
that is causing problems for the back-ends which pass arguments
differently depending on their type (i.e. Java, .NET, and C with
`--high-level-data').

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------