[m-dev.] Transitivity of import_module

[Fergus Henderson]

On 27-Sep-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> One thing that frequently bugs me is that if I import library A that uses
> stuff from libraries X, Y, Z in its interface, I also have to import X, Y, Z
> if I want to use those aspects of A.

That is a feature, not a bug.

C's `#include' style of transitive imports suck badly, because adding a
new symbol to one header file can cause name clashes in unrelated header
files that by coincidence happen to be connected by some chain of inclusions.
This is particularly bad in connection with macros, but similar problems
could arise in Mercury if imports were transitive.  In Mercury, if you're
using `import_module' rather than `use_module', name clashes for a
name defined in different modules can lead to ambiguity errors when
compiling code that uses that name.

Transitive imports lead to code that is significantly more fragile
and prone to breakage when upgrading to new versions of libraries.
For example, the following program is currently legal Mercury,
but might _not_ remain legal in more recent versions if your proposal
was accepted, because of a potential name clash.

	:- module example.
	:- interface.
	:- import_module io.
	
	:- pred main(state::di, state::uo) is det.

	:- implementation.

	:- type status ---> succeeded ; failed.

	main --> print(failed), nl.

Here the issue is that the new standard library module `exception'
defines a symbol `failed', and if `exception' is ever imported in the
interface of `io' or any of the modules that `io' imports (transitively),
then it would cause that program to fail to compile.  (`io' imports
`char', `string', `std_util', `list' directly, and `int', `set', and
`bool' indirectly.  None of these import `exception'... *yet*.)

Currently we go to a fair bit of effort to retain backwards compatibility
with previous versions to the greatest extent practicable.
This proposal would basically be a major loss as far as maintaining
backwards compatibility goes, IMHO, because it would greatly magnify the
effect of name clashes.

In addition, the `include_module' declarations currently provide useful
documentation: the `include_module' declarations in a module document
which other modules I need to search to find the definitions of symbols
used in that module.  With your proposal, they would be much less
useful, becaused they'd only document the tip of the iceberg.
And the space I'd need to search would often be much larger.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------