[mercury-users] Modules, Submodules and Instances.

[Ralph Becket]

Fergus Henderson wrote on 30 Jan:
> 
> > What exactly is the naming convention here?  Under 0.8.1 I take it
> > that bar and baz must be implemented in files foo.bar.m and foo.baz.m
> > respectively.
> 
> That's correct.

That's interesting, because
mercury-extras-0.8/complex_numbers/complex_numbers.m has the following
body:

	:- module complex_numbers.
	:- interface.
	:- include_module complex, imag.
	:- include_module complex_imag, imag_complex.
	:- include_module float_imag, imag_float.

but the modules imag etc. are all defined in files imag.m etc.  I
gather that complex_numbers.m is used in libarary generation?  Is this
a convenient abuse of the include_module directive or is something
deeper going on here?

> (Some people may consider `:- module foo__bar' to be better style, though.)

Indeed.

> The language reference manual is quite clear about this: all
> module names in use_/import_module declarations must be fully
> qualified.  This is stated twice, in the "The module system"
> sub-section and also in the "Visibility" sub-section of
> the "Modules" chapter.

Yes, it just seemed a little odd to have the distinction between
include_module and use/import_module, that's all.  Personally, it'd
find it more natural to require that include_module also be module
qualified.

> > (3.2) Does it matter where the include_module declaration goes?
> > Is there any difference between placing it in the interface or the
> > implementation section?
> 
> Yes, there is a difference.  If you put the "include_module" declaration
> in the implementation section, then that sub-module will be private;
> it can only be used by its parent module and by other sub-modules
> of the parent module.

I'm slightly confused here.  I was under the impression that
include_module only declares a module to be a sub-module.  The
name-space, however, is actually extended by use_/import_module.

Consider

	:- module foo.
	:- interface.
	:-	include_module foo__bar.
			% At this point, we only know that foo__bar
			% is a sub-module, we don't have access to
			% its interface.

If foo's interface goes on to to say

	:-	import_module foo__bar.
			% Now foo__bar's interface is part of foo's
			% interface.

then the interface of foo includes the interface of foo__bar.  So what
is the effect of putting `:- include_module foo__bar' in the interface
for foo, but not `:- import_module foo__bar'?

> See the third item in the "Implementation bugs and limitations"
> sub-section:
> 
>  |    * When using nested modules, the Mercury build tool Mmake sometimes
>  |      tries to build things in the wrong order and hence reports
>  |      spurious errors about `.int*' files not being found.  In these
>  |      cases, simply typing `mmake' again will usually solve the problem.

Mea culpa.  What's the solution if a second mmake doesn't do the
trick?

> Unfortunately there was a bug in 0.8 which meant that if the
> end-module declaration for a sub-module is the last thing
> in the containing module, the compiler would report a spurious error.
> This bug was fixed in our development sources on Dec 17.
> I've attached the patch.  The work-around, if you need to use 0.8,

'fraid the patch never made it through.

> is to use separate sub-modules rather than nested sub-modules,
> or to ensure that the end_module declaration for sub-modules
> is not the last thing in the parent module, e.g. by using an
> explicit end_module declaration for the parent too.

That sounds like a good solution, anyway.

> The reference manual is OK as a reference manual, I think.
> Most of your questions above were either answered by the
> reference manual or where due to confusion resulting from
> implementation bugs or limitations.

The RM is pretty good, but I don't think my questions were
tutorial-level stuff.  I was certainly having trouble squaring the
manual with the compiler with what (I thought) I was trying to do.

> The reference manual certainly doesn't do a great job as an introductory
> tutorial, but I think that should really be the job of a separate document.
> Adding some examples to the reference manual is probably a good idea, though.
> On the other hand, we also need
> 
> 	- a separate tutorial document,
> 
> 	- more work on the implementation, to fix the documented
> 	  bugs and limitations,
> 
> 	- and more examples in the samples directory and elsewhere,
> 
> and if we had all of those then there might be much less need for more
> examples in the reference manual.

I might have a stab at the tutorial one of these days...

> > (3.4) A Submodule Cannot Directly Implement Something
> > Exported From the Parent Module.
> > 
> > That is, I can't do...
> 
> Adding something along those lines to the language reference manual
> is probably a good idea; I'll put that on my list of stuff to do.

Ta.

> Mercury supports overloading.  Name clashes are reported only at the point
> of use, and only if there is an ambiguity.  Ambiguity resolution considers
> not only the name and any explicit module qualifiers, and depending on
> the kind of symbol used, it may also consider the arity and the type.

Yep.  Thanks for all that - most helpful!

Cheers,

Ralph

-- 
Ralph Becket  |  rwab1 at cam.sri.com  |  http://www.cam.sri.com/people/becket.html