[m-users.] problem with unique modes

[Zoltan Somogyi]

On Fri, 10 Jul 2015 13:07:57 +0100, matthias.guedemann at googlemail.com (Matthias Güdemann) wrote:
> [someone else]:
> > David Overton's thesis is a good source of information, and is
> > possibly what Ralph was referring to. It's available on the papers
> > page.
> 
> I read the paper "Constraint-based mode analysis of Mercury" (David
> Overton, Zoltan Somogyi and Peter Stuckey. PPDP'02, Pittsburgh) and some
> relevant parts of David Overton's thesis. Unfortunately, unique modes
> are explicitely not treated, it is mainly concerned with partially
> instantiated data-structures.

The two problems are closely related, because both require exact tracking
of the set of references to a piece of memory. In the case of unique modes,
you want to know when the set of references to an already bound variable
becomes the empty set, so you can reuse the memory of the term bound
to that variable. With partially instantiated data structures, you want to know
the set of references to a free variable, so you can update all those references
when the variable is bound. This EXACT tracking is the tricky part of both
problems. (If the analysis misses a reference, your program will crash in both cases.)

> If I understood correctly, then this is not supported in the compiler,
> therefore this is currently not used in the mode analysis.

The constraint based mode analysis described in that paper is in the Mercury
compiler, but it is experimental only, and not ready for real use. First, it
covers only a subset of Mercury, and second, its performance is not good enough.
The usual mode analysis algorithm is completely separate from this experiment.
 
> As I am using the FFI with stateful objects encapsulated in Mercury data
> types, I am interested in nested unique modes.

They won't be implemented anytime soon. David Overton's entire PhD was
about solving the similar problem of alias tracking, and that was not enough,
so the amount of labor required is quite substantial.

> Using
> unsafe_promise_unique/2 works, but having the compiler doing the checks
> would be nice.

If you could tell us more about the problem, maybe we could propose a
workaround.

Zoltan.