[mercury-users] Uniqueness modes etc

Zoltan Somogyi zs at cs.mu.OZ.AU
Thu Jan 8 21:40:14 AEDT 2004

On 08-Jan-2004, Dr Mark H Phillips <mark at austrics.com.au> wrote:
> I'm obviously not getting something (bear in mind that I am very new to
> mercury).  Now the type definition of generic was:
>   :- pred generic(..., pred(T, T)::in(pred(di, uo) is det), T::di,
>       T::uo) is det.
> so in the implementation of generic, T is an arbitrary type which it can
> make no assumptions about??  So it doesn't know what the di/uo pair is.
> It doesn't know if it is bits, fstate or I/O states.  Or does it?  If
> so, how??

No, the code of `generic' doesn't know.

> You say "If it is making a call with..." but the only call it is making
> which involves T, is the pred(T, T) that you will pass in.  So when you
> are implementing generic you can't know more about T than that it is
> some type can you??
> What am I not understanding?

That my post, Fergus's post and Ralph's posts were composed independently.
Their replies assumed a signature such as

:- pred generic(..., fstate::di, fstate::uo)
:- pred generic(..., bits::di, bits::uo)

and that is what I based my later message on.

If the fstate or bits type is abstract, as in their examples, then you
get similar levels of protection as with making the state be of a polymorphic
type. The difference between the two approach is how you control the set
of operations available on the state. In one approach, the set is the set of
operations exported by whatever module defines the abstract type; in the other,
it is the set of operations you pass as arguments to the generic computation.

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