[mercury-users] Modules, Submodules and Instances.
rwab1 at cam.sri.com
Sun Jan 31 03:12:39 AEDT 1999
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
:- module complex_numbers.
:- 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.)
> 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
> > (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.
:- module foo.
:- 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
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"
> | * 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
> 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.
> 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!
Ralph Becket | rwab1 at cam.sri.com | http://www.cam.sri.com/people/becket.html
More information about the users