[m-dev.] Module qualification of typeclass methods

[Peter Ross]

On Fri, Nov 16, 2001 at 06:07:39PM +1100, Simon Taylor wrote:
> On 15-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > Simon wrote:
> > > 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.
> 
> `:- include' is overkill for reducing the excessive number of imports
> needed to use the .NET libraries. The automatic import mechanism is a
> simpler, cleaner way of doing that.
> 
> In reply to Fergus's `:- include' proposal, Peter Ross wrote:
> > I think this proposal would be very useful for solving a problem
> > I am having with the fact that a namespace in .NET can reside over
> > more than one assembly.
> 
> I am trying to understand whether `:- include' is necessary for
> solving the .NET namespace problem.
> 
> If `:- include' is needed for solving that problem, then the automatic
> import mechanism is probably not needed as well.
> 
> If `:- include' is not needed for solving that problem, I'd
> rather it wasn't implemented at all.
> 
The .NET namespace problem has more then one aspect.

The System namespace resides in two different assemblies (mscorlib.dll
and System.dll).  There is also the problem that mscorlib.dll contains two
different namespaces, System and Microsoft.

The other problem is that the System.Xml namespace (located in
System.Xml.dll) is in Mercury terms a sub-module of System.  However
this means that to construct the System namespace we need to know all
the possible children modules so that we can add an `:- include_module'
for each of the children namespaces.  This isn't even possible at
interface generation time because someone may decide to extend the
framework with a new namespace.

There is however a way to resolve this problem.

For the mscorlib.dll, we could construct the module system as follows

:- module mscorlib.

  :- module mscorlib__System.

    :- module mscorlib__System__Object.
        % ...
    :- end_module mscorlib__System__Object.

  :- end_module mscorlib__System.

  :- module mscorlib__Microsoft.

    :- module mscorlib__Microsoft__Win32.
        % ...
    :- end_module mscorlib__Microsoft__Win32.

  :- end_module mscorlib__Microsoft.

:- end_module 

So in effect adding the assembly name as part of the name qualification.

In summary I thus don't think I need the `:- include' mechanism to solve
any of my current problems, that is not to say I will not need it in the
future.

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