[m-dev.] Module qualification of typeclass methods

[Peter Ross]

Simon wrote:
>
> On 16-Nov-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 12-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > 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.
> >
> > You're right.  This is indeed a drawback to this proposal.
> > For reasons that I explained earlier, I think it is a very
> > minor one, but I agree it is a drawback.
>
> ...
>
> > I think it's better to live with the drawback mentioned,
> > which I think will rarely be much of a problem in practice,
> > rather than complicating the language significantly in
> > order to solve it.
> >
> > > 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.
> >
> > I hope I have convinced you on this now?
>
> I can live with what you are proposing, but I don't much like
> either proposal for dealing with name clashes. If at all possible,
> I'd rather not implement `:- include' at all.
>
> I haven't seen a good explanation why the tool which
> generates the code to create a Mercury interface to .NET
> libraries can't do the combination of items from multiple
> assemblies into a single Mercury module itself.
>
Note that I haven't even began to talk about how to resolve names from
different assemblies which reside in the same namespace.  I was trying to
resolve my current problem first.

How do you suggest I resolve the following situation.

:- module system.
:- interface.
  :- module object1.
  :- interface.
  :- func name(t1) = string.
  :- end_module object1.

  :- module object2.
  :- interface.
  :- func name(t2) = string.
  :- end_module object2.
:- end_module parent.

The function `name' causes nameclashes.  The only way to resolve them is to
place them in submodules.  This I have no problem with.  What I have a
problem with is the fact that I need to import each of the sub-modules just
to use both object1 and object2 when what I would like to do is just import
system and get object1 and object2 at the same time.

Do I need to make myself clearer?

I have attempted to explain this all in most of my previous emails.  In
particular see the following for an explanation of how the current mapping
works.

http://www.mercury.cs.mu.oz.au/mailing-lists/mercury-developers/mercury-deve
lopers.0111/0058.html

Pete

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