2.3.1 Managing connections between modules

A Mercury module’s source file contains both the interface and the implementation sections of that module. Given a module A which imports module B, when compiling module A, the compiler needs to know what entities (types, predicates, functions etc) module B exports. It could do that by reading module B’s source file and extracting its interface part. However, given that the interface of a module tends to be much more stable than its implementation, that would be incredibly wasteful: it would compute B’s interface, many, many times, getting the same result between each pair of changes to B’s interface. It is far more efficient to store B’s interface in a file, which only ever needs to be updated when B’s source module changes, and does so in a way that affects its interface.

In C and in some programming languages based on it, hand-written header files (.h files) usually store the interface of the source file (.c file) with the same base name. Mercury programming uses a similar file, the .int file, with the difference being that a module’s .int file is not hand-written, but is derived from the module’s source file by the Mercury compiler.

In fact, due to Mercury’s module system being substantially more expressive than C’s (not hard when C does not actually have an explicit module system), each Mercury module has three or four interface files, not just one.

• .int files play the same role as C’s .h files: they list the entities (types, insts, modes, typeclasses, instances, predicates, functions, and some others) that this module makes available to the other modules that import it.
• .int2 files contain a subset of the information in .int files, the subset which the compiler needs from indirectly imported modules. (If module A imports module B and module B imports module C, but module A contains no :- import_module or :- use_module declaration for module C, then module A imports module C indirectly.)
• .int3 files contain just the names of the types, insts, modes, typeclasses and instances exported by the module. The compiler needs these files to construct A.int and A.int2 in the frequent case that module A’s interface uses a type named foo (maybe as the type of a predicate argument) that it does not define. If module A’s interface imports two modules, B and C, the compiler needs to know for each of those modules whether they define a type named foo, so it can put either B.foo C.foo as the type of that argument into e.g. A.int if just one of them defines it, and so that it can generate an error if either neither or both define it.
• .int0 files contain the declarations of the entities that a module that includes submodules exports just to those submodules, and to nowhere else. This includes entities (such as predicates and functions) that are declared in the implementation section of the parent module. Only parent modules, i.e. modules that include submodules, have .int0 files; non-parent modules no dot.

As you may guess from that description, managing Mercury interface files is not trivial. It is not hard either, as shown by Compilation details, but it is even simpler to leave their management to automatic build tools. These build tools also take care of another issue: separate compilation.

When C programmers update a header file, they must also recompile all the C source files that depend on that header file. Manually keeping track of which source files these are is possible in theory, but very tedious, and extremely error-prone. This is even more true for Mercury. Yet the one simple but guaranteed-to-work method, recompiling everything, can slow down the think-edit-compile-test cycle to an unreasonable degree. Unlike humans, automatic build tools can be trusted to recompile only the modules that need recompilation, reusing the results of previous compilations wherever possible.

The Mercury implementation supports two automatic build tools: mmake, and mmc --make. As their names imply, both are intended to work like the traditional Unix build tool make. The next two subsections describe them in turn. They each have strengths and weaknesses (for example, mmake supports only compilation to C, not to Java or C#), and they support different subsets of the available functionality, though the overlap (the set of features they both support) is large. We recommend that projects using Mercury pick one, and use it consistently.

If you can, you should pick mmc --make, because this is the build tool that is likely to receive more development in the future.

You can also use both tools, each for different parts of the same project, such as using mmc --make for the Mercury parts and mmake for tying those parts to the non-Mercury parts, but in general, you should do this only if you have to.