[mercury-users] Typeclass problem (bug, misunderstanding, oth er?)

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Aug 7 08:21:33 AEST 2000


On 06-Aug-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> > From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> > 
> > > Ahh.  This looks like a hole in type inference to me, now.
> > > From the typeclass definition and the typeclass constraint
> > > on solve/5 it can be deduced that PoppedNodes must have
> > > the same type as DummyNode:
> > 
> > No, it can't.
> > 
> > > :- typeclass csp(T, N) <= node(N) where [
> > > 	...
> > > 	pred pop_stack(list(N), T, T),
> > > 	...
> > > ].
> > > 
> > > :- pred solve(conflict_fn, bool, N, T, T) <= csp(T, N).
> > >
> > > So, N is related to T, the pop_stack/3 method returns a
> > > list of N, and we know that N is a polymorphically typed
> > > argument.
> > 
> > You're assuming here that the csp(T, N) instance
> > in the call to `solve' must be the same as that
> > in the call to `pop_stack'.  But there is no such
> > requirement.
> 
> Now I am totally confused.  If I write
> 
> :- typeclass csp(T, N) where [ pred pop_stack(list(N), T, T), ... ].
> 
> is it not the case that
> (1) T and N are *type* variables and that 

Yes, that's right so far...

> (2) given an instance csp(A, B) with X0:A, X:A (using : as a typing
> operator), declared as a typeclass constraint on a pred, then
> (3) a method call pop_stack(Ys, X0, X) in the body of the pred 
> implies that Ys:list(B).  

No.  It just implies that Ys has type list(C) with the constraint csp(A, C),
for some type variable C.  There is no requirement that C = B.

> The deduction Ys:list(B) relies purely on the typeclass definition,
> the typeclass constraint on the pred, the type of X0 and X, and the
> signature of the method call.

In order to typecheck a procedure call, one must rename apart the
type variables in the called procedure's type declaration before
unifying them with the calling procedure's type variables.
I think that in making that deduction, you omitted the renaming
apart step.

> If we take a trivial example:
> 
> :- pred eg(N, T, T) <= csp(T, N).
> :- mode eg(unused, in, out) is det.
> 
> eg(DummyN, T0, T) :-
> 	pop_stack(Ns, T0, T1),
> 	push_agenda(Ns, T1, T).
> 
> I just can't get my head around why the N in DummyN:N could be
> different from the N in Ns:list(N).  T0, T1, and T all have the
> same type.

Well, there might be multiple instance declarations for csp, e.g.

	:- instance csp(my_cst, int).
	:- instance csp(my_cst, float).
	:- instance csp(my_cst, string).

and even if the arguments to `eg/3' have T=my_cst and N=int,
the call to `pop_stack' could be intended to refer to a
different instance declaration, e.g. the one with `float'
rather than `int'.

Here's a different example which may make it clearer:

	:- typeclass printable(Stream, Type) where [
		pred print_method(Stream, Type, io_state, io_state)
		mode print_method(in, in, di, uo) is det
	].

	:- pred my_format(Term, Stream, io__state, io__state)
		<= printable(Stream, Term).
	:- mode my_format(in, in, di, uo) is det.

	my_format(Term, Stream) -->
		print_method(Stream, Term),
		print_method(Stream, ".\n").

In this hypothetical example, the predicate `my_format' here contains
two calls to `print_method', which is a method of the printable/2 type
class.  In the first call to print_method, the `Term' type parameter
in that call will have the same value as the `Term' type parameter
in the class constraint for `my_format'.  But in the second call,
the `Term' type parameter has a different value, namely `string'.
This second call shows that a type class method call from a procedure
with a type class constraint for that class need not have the same
values for the type class parameters.

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



More information about the users mailing list