[mercury-users] variable parameters in typeclass instances

[Michael Day]

Hi,

it does not appear to be possible to state the following:

% everything is an instance of the "pointless" typeclass:
:- instance pointless(_).

% everything and int satisfy the "strange_relation" typeclass:
:- instance strange_relation(int, T).

do these declarations have semantic problems that make them undesirable,
or will they be supported in a future version of the compiler?

The reason I ask is that it would appear to be necessary to do anything
useful with constructor classes when implementing collections. For
example consider a bag typeclass:

:- typeclass bag(B, T) where [

	pred insert(T, B(T), B(T)),
	mode insert(in, in, out) is det,

	...

this states that the type constructor B of arity 1 and the type T satisfy
the bag type class if they support insert, etc etc. The problem arises 
when it comes to declaring instances of this type class. If a list can be
used to implement a bag you might want to say the following:

:- instance bag(list, T).

This seems a valid way of stating that the type constructor list and any
other type satisfy the bag type class. Of course it currently does not
compile due to lack of constructor classes, but also because variables are
not permitted in instance declarations. Will this change? Is there
something I've overlooked?

Something that has just occurred to me that I should probably defer
mentioning until I've thought about more but will say anyway (whew) is
whether it would be advantageous to be able to curry types when using
constructor classes. A natural implementation of bag(T) is map(T, int),
and you can probably guess where I'm going with this. Okay, it's not going
to work, if currying works from the left. Rather than dream up some
arbitrary field based currying system lets pretend that the map
constructor specifies the value first and then the key. So we can
implement a bag(T) using a map(int, T). Now if we can partially specify
(curry?) the constructor in the instance declaration...

:- instance bag(map(int), T).

if we suspend disbelief for a few seconds it looks nice, bag requires that
the first argument be a type constructor of arity 1, which is what
map(int) is assuming we can curry type constructors in that fashion. The
second argument of map gets bound to T by the use of B(T) inside the
definition of bag.

Alright at this point I guess disbelief kicks back in. Currying seems like
it would cause a fair bit of grief for overloading, I can't see at this
point whether there is enough information for the compiler not to sulk.
And currying arguments from the left is weak and in this case useless,
given that we wish to curry the right most argument - however I believe
that kind of debate has cropped up more than once on this list, so perhaps
I will retreat to read what has been said earlier.

Oh incidentally this message has an implicit disclaimer of "if at any
point I am seen to be jumping through hoops to do something when there is
a much easier way, please tell me" - Thanks :)

Michael


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