[m-rev.] for review: allow arbitrary types in class constraints

[David Jeffery]

> Index: hard_coded/typeclasses/arbitrary_constraint_pred_2.m
> ===================================================================
> RCS file: hard_coded/typeclasses/arbitrary_constraint_pred_2.m
> diff -N hard_coded/typeclasses/arbitrary_constraint_pred_2.m
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ hard_coded/typeclasses/arbitrary_constraint_pred_2.m 6 May 2002
00:01:49 -0000
> @@ -0,0 +1,34 @@
> +:- module arbitrary_constraint_pred_2.
> +:- interface.
> +
> +:- import_module float, io.
> +:- import_module list.
> +
> +:- typeclass solver_for(B, S) where [
> + func coerce(B) = S
> +].
> +
> +:- instance solver_for(list(T), float) where [
> + coerce(_) = 42.0
> +].
> +
> +:- pred mg(T, T) <= solver_for(list(T), T).

I think you'll find problems with constraints like this on
predicate signatures.

Try something of the form:

:- pred p(T, T) <= c(list(T)).
:- mode p(in, in) is semidet.

and in the body 'p', do something which requires the
type-info for 'T' to be extracted from the constraint. e.g.

p(X, Y) :-
    ...,
    X = Y. % This unification requires the type-info for T

You should probably also try a few other cases which
involve using the type-info for constrained types.

Could you also add tests in the invalid/ directory for the
cases where your new 'loop checks' get triggered in
typecheck.m? Thanks.


dgj

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------