[mercury-users] Re: Universal type instance declaration

[Ralph Becket]

The Mercury users' mailing list is the appropriate forum for questions
like these.

Andr? Platzer, Tuesday,  5 August 2003:
> Hello!
> 
> When using mixed existential and universal types, I have been 
> experiencing problems with the declaration of parameteric types being 
> instances.
> 
> Considering the following program
> -------
> :- module tst.
> :- interface.
> :- import_module io.
> 
> :- typeclass especial(P,A) where [
>                 pred doit(P, A),
>                 mode doit(in, out) is semidet
>                 ].
> 
> :- all [A] some [P] (func create(A) = P => especial(P,A)).
> :- mode create(in) = out is det.

The universal quantifier is not necessary.

> :- pred main(io__state::di, io__state::uo) is det.
> 
> 
> :- implementation.
> 
> :- import_module list, require, std_util, string.
> 
> :- type veryspecial(A)
>    ---> ctspecial(
>               A
>              ).
> :- instance especial(veryspecial(A),A) where [
>    doit(P, "BUH")
>  ].

There are two problems here.

The first is that your instance declaration includes A on its own and is
therefore not legal Mercury.  From the reference manual section on
"Instance declarations":

	An `instance' declaration gives a type for each parameter of the
	type class. Each of these types must be either a type with no
	arguments, or a polymorphic type whose arguments are all
	distinct type variables. For example int, list(T) and
	bintree(K,V) are allowed, but T, list(int) and bintree(T,T) are
	not.

The second is that your definition of doit/2 has something of type
string for its second argument whereas your instance and type class
declarations would indicate something of type A.

> P.S. When do you expect partially instantiated data structures to be 
> available in Mercury? And what about implementing invokations of 
> nondeterministic predicates with coroutines for faster "turn-around 
> times" of multiple matches?

For the first question, I'm working on the analysis very slowly in the
little bits of spare time I have at present.  If the analysis works and
works efficiently, then we'll add it to the language.

For the second, the fastest mechanism is probably to call solutions on
the producer predicate and pass the result list to the consumer
predicate - no need for concurrency at all!

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