[mercury-users] Uniqueness modes etc

[Dr Mark H Phillips]

Hi,

I am new to this mailing list and I must confess, am
not a true Mercury user at this stage, but I am very 
interested in the language.  My main development
language at work is (by necessity) C++, however I am
making heavy use of a library called FC++ which allows
me to do "haskell-like" programming within C++.  FC++
basically provides lazy lists, polymorphic functoids,
together with most of the Haskell prelude (and more
besides).  Of late I have been thinking about 
the uniqueness typing ideas provided by Clean, and I
believe also by Mercury.  (I should also state that
I am fairly new to the ideas and have only read a
little about them.)

I have actually implemented a templatized wrapper
class in C++ which turns a normal C++ class into
a "uniqueness class".  Unfortunately it only does
uniqueness checks at runtime, but at the moment
I don't see any easy way of doing it at compile-time
within the C++ type system.

Now, getting to my question...

I have been reading the Mercury tutorial on modes:

  http://www.cs.mu.oz.au/research/mercury/tutorial/modes-n-insts.html

where it talks about the di and uo modes which appear to stand for 
"dead-input" and "unique-output".

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?  Ie
what really would be happening is that x would be unique as it goes in,
is destroyed, and then a new version created on output.  Ie, providing
the possibility of modify-in-place, keeping the same name.  I think
Clean allows this, letting you write

  x = modify x

although I'm not sure whether this is only a short-cut notation provided
for local variables.

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

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.

My question is: can this form of "pseudo opacity" actually happen inside
Mercury?  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.

I'm interested in people's thoughts --- or if I'm missing some crucial
basic knowledge (which is quite possible), perhaps people could direct
me to some reading material.

Oh, and have a great Christmas all!  (I won't be able to read my email
on public holidays/weekends, but I will be able to read it the rest
of the time.)

Cheers,

Mark Phillips.


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