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

[Ralph Becket]

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> > solve(CFn, Solved, DummyNode) -->
> >     ( if top_exhausted then
> >         pop_stack(PoppedNodes),
> >         push_agenda(PoppedNodes),
> 
> OK, you've passed the DummyNode in; but you haven't done 
> anything with it.
> So the type of PoppedNodes is still unconstrained.
> You need to add some code to constrain the type of PoppedNodes
> so that it uses the same node type as that used for DummyNode,
> e.g. a call to
> 
> 	  { PoppedNodes `has_same_type_as` [DummyNode] }

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:

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

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