[m-dev.] Module qualification of typeclass methods

[Fergus Henderson]

On 14-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> On Tue, Nov 13, 2001 at 08:14:24PM +1100, Fergus Henderson wrote:
> > On 12-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > This `:- include' proposal doesn't solve the problem of
> > > including all of the sub-modules of modules such as
> > > extras/complex_numbers/complex_numbers.m,
> > 
> > Sure it does, just put an `:- include' declaration in the parent module
> > that includes the appropriate child modules.
>
> I don't think it does solve the problem.  You stated before that an
> export_module declaration will override the namespace qualifiers with
> that of the current module, so for every sub-module you include using
> this mechanism will lose its sub-module qualifier.  Probably leading to
> name conflicts, which is the reason why you put it an item in a
> sub-module in the first place.

For cases like extras/complex_numbers, the ambiguity will be
resolved by the types of the arguments.

> Could someone please comment on what the following sentence means in the
> Reference manual.
> 
>   If an `:- include_module' declaration occurs in the interface section of
>   a module, then only the declarations (interfaces) of the sub-modules are
>   included in the parent module's interface; the definitions
>   (implementations) of the sub-modules are considered to be implicitly
>   part of the parent module's implementation. 

It means that if you write

	:- module foo.
	:- interface.
	:- include_module bar.
	:- implementation.
	:- end_module foo.

where foo.bar.m contains

	:- module foo__bar.
	:- interface.
	:- func answer = int.
	:- implementation.
	answer = 42.
	:- end_module foo__bar.

then this is equivalent to

	:- module foo.
	:- interface.
		:- module foo__bar.
		:- interface.
		:- func answer = int.
		:- end_module foo__bar.
	:- implementation.
		:- module foo__bar.
		:- implementation.
		answer = 42.
		:- end_module foo__bar.
	:- end_module foo.

rather than being equivalent to

	:- module foo.
	:- interface.
		:- module foo__bar.
		:- interface.
		:- func answer = int.
		:- implementation.
		answer = 42.
		:- end_module foo__bar.
	:- implementation.
	:- end_module foo.

(which would be an error).

> I think it means that any definitions of the sub-module are visible when
> the parent modules definitions are visible.

Nope.  The sub-module needs to be imported using an explicit import_module
or use_module declaration for the declarations in the sub-module to be
visible.

> So I propose that we overload the meaning of an `:- include_module'
> which appears in the interface section of a module to mean that you
> should also automatically import that module.

I think that would be a bad idea.
It would mean that there was a semantic difference between
nested sub-modules and separate sub-modules, which I don't
think is a good idea.  I also think it would be bad to make
`:- include_module' do two different things at the same time.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  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
--------------------------------------------------------------------------