[mercury-users] variable parameters in typeclass instances

[Peter Schachte]

On Fri, Nov 12, 1999 at 07:05:36PM +1100, Fergus Henderson wrote:
> > 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).

I was deliberately avoiding that phrasing, because it suggests a
hierarchy of specificity, when what I had it mind was a simpler
Boolean model:  either the type explicitly specifies a method for
universal type class operation, or it gets the default one.

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

You were worried about semantics; I was just arguing that a reasonably
clean semantics is not only possible, but already in use elsewhere in
Mercury.

Anyway, what we're talking about would of course directly conflict
with point (1), but I think point (2) would be a fair compromise for a
general universal type class feature, if it made implementation
easier.  I suspect, though, that without (1), it wouldn't help.  It
may be that the best way to implement this sort of feature would be
using a simple switch-on-type sort of technology, rather than a
dispatch-through-virtual-table one.  This would probably be
considerably more space-efficient where most types just accept the
default method.  Time efficiency would suffer a bit, but it would
probably be a fair compromise, considering the alternatives.


-- 
Peter Schachte                     Any man who is under 30, and is not a
mailto:schachte at cs.mu.OZ.AU        liberal, has not heart; and any man who
http://www.cs.mu.oz.au/~schachte/  is over 30, and is not a conservative,
PGP: finger schachte at 128.250.37.3  has no brains. -- Winston Churchill 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------