[m-dev.] [reuse] fixes of some naughty bugs

[Peter Schachte]

On Mon, Mar 12, 2001 at 08:49:54AM +0100, Nancy Mazur wrote:

> > 	X = f(Y,Z), p(X), q(Y).
> > 
> > If p/1 is allowed to destructively modify X in an equivalence-preserving
> > way, then q/1 may be called with different copy of Y depending on in which
> > order the first two goals are executed.  Reordering is no longer quite as
> > safe.  Of course, there's no logical difference, but there is an operational
> > difference.
> 
> I don't really get this here.

My comment wasn't about structure reuse.

Suppose we defined p/1 as:

	p(Term) :- 
		Term = f(X, Y),
		X = Y,
		destructively update first argument of Term to be Y.

If X and Y are big, this will free up a lot of space at the next GC.  But
Mercury compilers are allowed to reorder conjunctions, so there's no way
for a programmer to write

	p(X), X = f(Y,_), q(Y)

and be confident the X = f(Y,_) won't be moved before the call to p/1,
thereby screwing up the GC possibility.

> > I'm a bit concerned about doing this kind of thing on a type with a
> > user-defined equivalence predicate.
> 
> Again, I don't get this here.

Again, I wasn't talking about reuse, just about what should be allowed in
Mercury programs, and what that costs in optimizations made impossible.

> My general statement
> about the aliasing in the context of foreign code was that we consider
> modes- en type-declarations to be correct, and try to deduce as much
> as possible from that. And indeed, if a predicate has some unique 
> variables, than we consider that they don't have any aliases. 

Cool.  That's better than I thought from your earlier message.

Now we just need to get people to write *all* the modes for their foreign
code, so we can take advantage of this.

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  What we cannot speak about we must
http://www.cs.mu.oz.au/~schachte/      pass over in silence.
Phone:  +61 3 8344 9166                    -- Wittgenstein 
Fax:    +61 3 9348 1184                
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------