[mercury-users] variable parameters in typeclass instances

[Fergus Henderson]

On 12-Nov-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Fri, Nov 12, 1999 at 03:16:57PM +1100, David Glen JEFFERY wrote:
> > ... there are plenty of examples where it would be nice
> > to be able to provide a `universal' instance as well as more specific 
> > instances. The problem here is that it does make the semantics (and probably
> > the implementation) rather more complicated because in these cases there may
> > be more than one instance declaration that could be applied (`overlapping'
> > instances). 
> 
> I think you need a "explicit instance declarations always override
> implicit ones" kind of semantics.  For example, suppose every
> discriminated union type is `printable', using functor and arg to
> print them.  You'd want to be able to specify that your new foo type
> is `printable', but supplies its own print method.

Ah, but surely the generic instance declaration using functor and
arg would be explicit too, wouldn't it?  I think perhaps you mean
"more specific instance declarations always override less
specific ones" (where one instance declaration is more specific
than another if there is some binding of types in the more general
one which would make it the same as the more specific one).

That is the approach taken by one of the extended Haskell
implementations (Hugs or ghc, I forget which).
But it has problems for separate compilation and for
modularity.  What should happen if there is a more
specific instance declaration, but that declaration is
not visible, for example because it is defined in the
implementation (not the inferface) of one of the imported
modules?

> There's nothing unprecedented about this:  Mercury already handles this
> for the implicit universal "unifiable" type class, where users can
> define their own equality predicate which overrides the default one.

There are several significant differences between that and allowing
overlapping instances in general.

With what we currently have

	(1) there's a fixed set of type classes and methods
	    that can be overridden

	(2) the declaration saying that they are overridden
	    is part of the type, not in a separate instance declaration
	    (that might occur in a different module)

The implementation technique used for user-defined equality
relies on both of these properties.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------