[m-dev.] Module qualification of typeclass methods

[Tyson Dowd]

On 30-Oct-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 30-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > Simon wrote:
> > >
> > > On 30-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > > On Tue, Oct 30, 2001 at 05:23:29PM +1100, Tyson Dowd wrote:
> > > > > On 29-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > > > > However we could allow the typeclass declaration to introduce a new
> > > > > > namespace, thus the fully qualified name would become
> > > > > >
> > > > > >     mod__foo__bar(X)
> > > > >
> > > > > Can you explain to the viewers at home what the problem is with
> > > > >
> > > > > :- module mod.
> > > > > :- module foo.
> > > > > :- typeclass foo(T) where
> > > > > [
> > > > >     bar(T) = int
> > > > > ].
> > > > > :- end_module foo.
> > > > >
> > > > > Which appears to do the same thing...
> > > > >
> > > > To use the typeclass foo one must now import the module mod__foo.  This
> > > > must be done for each typeclass the user wishes to use.  This seems
> > > > unecessary to me because we already have another mechanism we could use
> > > > for distinguishing between two typeclasses at the same module level.
> > > >
> > > > However the current option of using sub-modules doesn't sound too
> > > > bad until you consider how it scales.
> > > >
> > > > Our prototype system for interoperability with .NET objects maps each
> > > > object to a typeclass.  Each of these typeclasses may have names which
> > > > conflict with the same name in another typeclass, hence we have to place
> > > > each typeclass in a seperate sub-module.  The mscorlib assembly has 883
> > > > public types in it, so a reasonable use of this library may require 20
> > > > or 30 imports just to use a subset of its types effectively.  I can
> > > > assure you that this is very annoying.
> > >
> > > Would it be better to add an `import_package' declaration, which
> > > is like `import_module', but also imports all sub-modules of the
> > > imported modules.
> > >
> > This could be problematic when you have a very large hierachy of sub
> > modules.  For instance if you want to use the System namespace in .NET you
> > would also have to load in all the children namespaces.  This would be huge,
> > so maybe it is not such a great idea because it could lead to too much
> > importing.
> 
> How about a different type of `include_module' declaration for which
> the child module is always imported when the parent is imported?

This is similar to the 

import foo.bar.*

constructs that occur in several other languages.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------