[mercury-users] overlapping instance declarations

[Peter Schachte]

On Sun, Aug 06, 2000 at 05:11:13PM +1000, Michael Day wrote:
> 
> Would it be possible, meaningful or useful to allow overlapping instance
> declarations, as long as they are in separate modules?
> 
> Currently, instance declarations are global and overlapping instances are
> detected at link time. If all instance declarations were module qualified
> in some way, this link time check could be skipped, if there was a check
> to ensure that the instance declarations in a particular module did not
> overlap.

But which module?  Suppose I have a predicate p that uses an instance method m
for a type class c.  When p is called by q, it is passed an argument of type
t.  Each of p, q, c, and t can be in different modules; which should have its
overlapping instance declaration respected?

> It seems that it would be very easy to get into a situation where you are
> stuck with an instance declaration you don't like, but can't replace. What
> happens when you want your own :- instance hashable(string). when someone
> has thoughtlessly already taken it? What happens when you want a number of
> instances of ring(float) using different operations?

I agree, this is a problem.  I suppose you can work around it by defining
wrapper types with their own instance declarations, but if it happens much,
it'll be pretty ugly.

> Linking in one extra
> module to a working program can introduce link errors if that module has
> an instance declaration that already exists in the program, even if the
> instance declaration is not exported and no other modules are using it.

Worse yet, adding an instance declaration to an existing library module can
break existing code.  This is quite bad, because when the library starts to
really use type classes, adding instance declarations should be seen as a good
thing, because it provides new predicates that can operate on existing types.

> That doesn't feel right.

I agree.

Here's a thought experiment.  Suppose predicate q calls p passing a term of
type t in a position where an instance of type class c is expected, and
suppose t is not declared to belong to class c.  Should I be able to fix this
by linking in a completely different module m that contains the needed
instance declaration?  Somehow, that doesn't seem right to me.  Why should I
feel the effect of an instance declaration in a module I don't import?

It would be nice to have some kind of precedence of instance declarations, so
a module could supply a "default" instance declaration for a type it defines,
but a module that actually uses that type could make its own instance
declaration, which would take precedence for calls made from that module.

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  Almost everything starts out as a
http://www.cs.mu.oz.au/~schachte/      good idea before it turns into a
Phone:  +61 3 8344 9166                buzzword.
Fax:    +61 3 9348 1184                    -- Greg Alexander 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------