[mercury-users] Uniqueness modes etc

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


On 08-Jan-2004, Dr Mark H Phillips <mark at austrics.com.au> wrote:
> > :- pred generic(..., pred(T, T)::in(pred(di, uo) is det), T::di, T::uo) is det.
> 
> And what is
> it, in Mercury, which makes a parameter have polymorphic type?

The fact that it's type contains a type variable, in this case T.

> By the way, should those T's actually be T0, T1, T2 and T3?

Not in my example. T represents the type of the state. The predicate
`generic' doesn't know what type that is, but it must be one type,
otherwise the output of the pred you pass in won't be acceptable as its input.

> So what you've illustrated above is that, by using polymorphism, a
> generic pred can guarantee that it will only work with state in a
> generic way.  (Though it is still possible for it to stuff up the
> order of state transitions.)

If you want generic to make more than one state change, such stuffing up
is always possible. You can of course put a finite state machine in
the state to check whether this happens at runtime, if some sequences
of state transitions are forbidden.

> But what if I want a stronger 
> guarantee: that a given state-changing computation can _never_
> have the details of its state changing played with inappropriately.

I do not know what you mean, since I don't know what criterion you use
to distinguish appropriate from inappropriate.

Note that absolute information hiding is not feasible, since the generic
predicate may call C code that has access to the entire address space
of the process.

> How can the use of mutvar hide the fact that state is changing?  I
> thought you still needed to pass the store in and out?

You can use the I/O state as a store, so the generic code wouldn't
know whether you are changing any state other than the I/O state.

> Why do you strongly advise against this approach?  What are the
> negatives?

I advise against it precisely because it hides whether you are doing
I/O or some other kind of state change.

Zoltan Somogyi <zs at cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne
--------------------------------------------------------------------------
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