[mercury-users] type class constrain problem

Ralph Becket rafe at csse.unimelb.edu.au
Mon Aug 6 09:31:09 AEST 2007

Hi Andrea,

Andrea Bini, Friday,  3 August 2007:
> hi all!
> suppose you have two modules, one declaring:
> :- typeclass c1(T) where [ ].
> :- instance c1(tc1_1) where [ ].
> :- instance c1(tc1_2) where [ ].
> :- type tc1_1 ---> foo.
> :- type tc1_2 ---> bar.
> :- type t1 ---> some [T] t1(T) => c1(T).
>    %  t2 contains constructors for all and only the types of class c1
>    %
> :- type t2 ---> fooc(tc1_1)
>                     ; barc(tc1_2).
> and the other one that needs to construct a term of type t1 from a t2 term
> but without explicitly nominate t2 constructors (i.e. needs to work without
> being rewritten if declarations in the first module change). Writing a
> predicate as the following doesn't work becouse the compiler says that the
> type class constrain is unsatisfiable:
> :- pred t2_to_t1(t2::in, t1::out) is semidet.
> t2_to_t1(T2,T1) :-
>   type_ctor_and_args(type_of(T2), _, [X_desc]),
>   has_type(X, X_desc),
>   T1 = 'new t1'(X).

There are a few problems here, the main one being that has_type only uses
its first argument's type info, not the argument itself.  X has mode
`unused' here (which means `free >> free'), hence X does not become
ground as required.

> my question is: I need to write a predicate, that does the same thing of
> t2_to_t1, in the first module but specific to the particular t2 keeping it
> updated if declarations are changed, like this:
> :- pred t2_to_t1(t2::in, t1::out) is det.
> t2_to_t1(fooc(X), 'new t1'(X)).
> t2_to_t1(barc(X), 'new t1'(X)).
> or there is a way to modify the generic t2_to_t1 and let it works?

The generic version requires dynamic type class casts, which has been on
our wish list for quite a while now.  Unfortunately it's an extension that
requires non-trivial changes to our run time type information
implementation and we haven't got around to completing those changes.

Can you live with the less generic version for now?  It's preferable in
many ways because the compiler can verify your code, which it's unlikely
to be able to do in the generic implementation.

-- Ralph
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au

More information about the users mailing list