[mercury-users] Uniqueness modes etc

[Fergus Henderson]

On 24-Dec-2003, Dr Mark H Phillips <mark at austrics.com.au> wrote:
> Is it possible to have a variable, x say, and send it into a function
> using the di mode, and extract it out again using the uo mode?

Yes.

> Now I am assuming that you can do some form of currying in Mercury.
> Suppose we have some:
> 
>   :- pred r(int, int, int, int).
>   :- mode r(di, uo, in, out) is det.
>   r(x, y, n, fn) :- ....
> 
> (please excuse me if I've got the syntax wrong)

Variable names in Mercury start with a capital letter,
so this should be

	r(X, Y, N, Fn) :- ....

but otherwise that is fine.

> Now suppose we form a "curried" form of this:
> 
>   let q(n, fn) be r(x, y, n, fn) where x and y have both been set to
>   some variable x_0.

The Mercury syntax for this would be

	X = X_0,
	Y = X_0,
	Q = (pred(N::in, Fn::out) is det :- r(X, Y, N, Fn))

> Now presumably q could be "applied" to several different n, producing
> in turn several different fn.  Now r is referentially transparent,
> but because q has uniqueness modifying behaviour hidden away inside
> the "currying", q acts as if it is referentially opaque.  Ie, on each
> application, x_0 may be modified, potentially giving rise to different
> q behaviour down the track.

Indeed, if code like this was allowed, that would be a problem.

> My question is: can this form of "pseudo opacity" actually happen inside
> Mercury?

No.  Code like the above is not allowed.  You can't partially apply
a procedure if the partially applied arguments have "di" modes.
You will get a mode error (well, actually a uniqueness error),
e.g. something like this one:

	in argument 1 of call to predicate `f.r/4':
	mode error: variable `X' has instantiatedness `ground',
	expected instantiatedness was `unique'.

> And what is the best way of thinking about these issues?  Ie,
> this kind of behaviour can be quite useful -- certainly in C++ it can
> be -- is it a problem or is it theoretically fine?  Or should I be
> modelling this kind of thing differently.

If you _want_ this kind of behaviour, then I think the right way of modelling
it in Mercury would probably be to use a "mutvar" -- see the "store" module
in the Mercury standard library.  Feel free to ask if you have any questions
about this approach.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------