[m-dev.] Module qualification of typeclass methods

Peter Ross peter.ross at miscrit.be
Tue Oct 30 20:17:24 AEDT 2001


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:
> > DJ and I were discussing the merits of the following change.
> > 
> > Currently for the following code
> > 
> > :- module mod.
> > :- typeclass foo(T) where
> > [
> >     bar(T) = int
> > ].
> > 
> > 
> > if we wish to use the fully qualified name for the method bar it is
> > 
> >     mod__bar(X)
> > 
> > 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.

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



More information about the developers mailing list