[m-dev.] Module qualification of typeclass methods

[Fergus Henderson]

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)
> 
> This change has the advantage that more than one typeclass at the same
> scope can have a method with the same name and for these names to be
> distinguishable.  This is useful for doing interoperabilty on the IL
> backend.  It makes the mapping between objects and typeclasses much more
> natural.
> 
> The disadvantages of this change are: it is not backwards compatible and
> it no longer allows a typeclass method to easily become a normal
> predicate, as any qualified uses of that name will have to be adjusted.

Another possibility would be to say that the fully qualified name for
the method bar is `mod__foo__bar', but that the method can *also* be
referred to by the name `mod__bar' whenever this is unambiguous
(using the normal rules for resolving ambiguities).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------