[m-dev.] Module qualification of typeclass methods

[Peter Ross]

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.

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