[m-dev.] Module qualification of typeclass methods

[Fergus Henderson]

On 15-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> On Thu, Nov 15, 2001 at 04:43:39PM +1100, Fergus Henderson wrote:
> > On 14-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > 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.
>
> One I propose to allow include_modules declarations for nested
> sub-modules.  An include_module for a nested sub-module in the interface
> will have exactly the same effect as for a seperate sub-module (except
> that the compiler is smart enough to figure out it already has the
> module).

That would mean that there's no way of having a separate sub-module
with the same semantics as a nested sub-module for which the parent
module doesn't have an include_module declaration.

That's why I don't like this proposal.
Whether I choose to use nested sub-modules or separate sub-modules
should just be a matter of how I arrange the source code,
it shouldn't affect the semantics.

> An include_module in the implementation does nothing.

That seems like a bad idea; if the declaration has no effect, then the
compiler ought to issue a warning, and in that case we might as well
make it an error.

> Note
> that currently the Mercury compiler accepts include_module declarations
> for sub-modules.  This needs to be fixed otherwise.

Yes.

> One Simon has added a section about the difference between
> implementation and interface sub-modules to the reference manual.  The
> compiler doesn't obey these rules.  I have used implementation
> sub-modules from modules that weren't the parent module.  This will also
> need to be fixed if we don't add to the meaning of include_module.

Are you sure?  There's a test for this in tests/invalid;
the files in question are test_nested.m, parent.m, and parent.private_child.m.
The compiler correctly reports an error in this case.

There's a related case in parent.undeclared_child.m,
which currently we don't detect.  That does need to be fixed.
(The comment in tests/invalid/Mmakefile, explaining why this
test cases is commented out, says "just not yet implemented".)
Maybe that is what you're thinking of?

-- 
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
--------------------------------------------------------------------------