[mercury-users] Uniqueness modes etc

[Dr Mark H Phillips]

On Tue, 2004-01-06 at 19:01, Zoltan Somogyi wrote:
> On 06-Jan-2004, Dr Mark H Phillips <mark at austrics.com.au> wrote:
> > The question is: how does one implement a generic
> > computation, that itself takes a generic state-changing computation
> > as a parameter, and yet keep the state-changing details hidden from
> > the generic computation?
> 
> If by "state-changing details" you mean the details of how the state
> changes work, it can be done trivially: give the generic computation
> a signature like this:
> 
> :- pred generic(..., pred(T, T)::in(pred(di, uo) is det), T::di, T::uo) is det.
> 
> That is, you pass in the state-change predicate and an initial state, and
> get back the final state. Since the state is of a polymorphic type, generic
> can't look inside it.

Okay, so what you're saying (I think) is that by using a generic
(polymorphic) parameter T, we can guarantee that "generic", the pred,
can not make use of any structure that is actually passed in as T.
Thanks for this.  

By the way, should those T's actually be T0, T1, T2 and T3?  And what is
it, in Mercury, which makes a parameter have polymorphic type?

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.)  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 am guessing to safe-guard this we would need to curry a mutvar
reference, giving access to only the store.  (Correct threading
is still an issue.)

I am also wondering whether a monadic approach could provide such
safe-guards, along with correct threading safety.

> If you want, you can avoid passing the state change predicate explicitly
> by making it an operation of a type class, named say "state_change":
> 
> :- typeclass state_change(T) where [
> 	pred state_change_pred(T::di, T::uo) is det
> ].
> 
> :- pred generic(..., T::di, T::uo) is det <= state_change(T).
> 
> This is especially convenient if there are several operations on the state
> being passed around.
> 
> If by "state-changing details" you mean you don't want generic to know
> even that some state is being changed, then you can use mutvar, but I would
> strongly advise against this if the first approach is feasible.

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?

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

Thanks for your input,

Mark.


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