[m-dev.] Module qualification of typeclass methods

[Fergus Henderson]

On 12-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 01-Nov-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 01-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > 
> > > On 31-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > > Fergus wrote:
> > > > To make this clear:
> > > > 
> > > > :- module foo__bar.
> > > > :- export_module baz__bar__foo.
> > > > :- end_module.
> > > > 
> > > > Would replace all module qualifiers baz__bar__foo with foo__bar on the items
> > > > in baz__bar__foo.
> > > > 
> > > > > % combining two modules into a single module:
> > > > > :- module foo.
> > > > > :- interface.
> > > > > :- export_module bar.
> > > > > :- export_module baz.
> > > > > :- end_module foo.
> > > 
> > > How would this handle the case where `bar' and `baz' define
> > > a predicate, type, mode, etc. with the same name?
> > 
> > That would be allowed, but attempts to refer to such
> > a predicate, type, or mode `x' via the name `foo__x'
> > might result in ambiguity errors.  These ambiguities
> > could be resolved by referring to it via the name `bar__x'
> > or `baz__x'.
> 
> When `:- export_module' or `:- include' is being used to
> combine two modules, I think it's a bit ugly to have to
> know how the combined module was constructed.

Generally you won't.  The only time you would need to know that is in
the case where
- the two combined modules happen to have some name clashes, and
- you happen to refer to a name that is defined in both modules, and
- this occurs in a situation where the compiler can't determine
  which one you mean from the context.

If such an ambiguity does occur, the compiler error message could give
you a list of the possible modules that the name originally came from --
then you wouldn't need to know how the combined module was constructed,
because the compiler would tell you all you needed to know.

> I also don't like the idea of relaxing the restriction that
> there can only be a single predicate or function with a
> given name in a module. That every predicate or function
> has a unique fully qualified name without looking at the
> argument types is very useful for readability.

But every predicate or function does have a unique fully qualified name.
The proposal would just mean that some predicates or functions have
additional aliases.

For cases where you need to concisely and unambiguously refer to a predicate
(e.g. in compiler error messages, and in tools such as the debugger and
profiler), you can still use the unique fully qualified name, without
needing to specify the argument types.

So I think this proposal retains the most important advantages of
this restriction, while significantly increasing expressiveness.

> Instead, I would suggest allowing renamings, for example
> :- include bar where [pred x/1 is y].

Ugh.

This goes against the principle of resolving ambiguity at
the point of reference (where it is an actual ambiguity),
rather than at the point of definition (where it is merely
a potential ambiguity).

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

Note that although in this particular case that means all child modules,
in general you might often want to do this for just a subset of the child
modules.

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