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

[Nancy Mazur]

> > 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. Reordering is indeed an unsafe operation
> with regard to structure reuse, in the sense that no reordering should
> be allowed after the structure reuse-pass has done its job, at least not
> in the predicates in which reuse has been discovered. 
> But I don't see how this is a concern for the user in the first place?
> 
> Concerning your example, it's not sure that in any of the two orderings
> you are talking about reuse may be allowed. 
> 	
> 	X = f(Y,Z),	% generates alias (X/f/1, Y), (X/f/2, Z)
> 	p(X),		% where part of X is in local forward use (Y), 
> 			% so if reuse is allowed, then only of the Z-part. 
> 			% Y itself cannot be touched. 
> 	q(Y)		%... 

Small correction: not only Y cannot be touched, but also f(_,_)
cannot be reused. 

> in the other ordering, there is no chance reuse will be allowed... 

whoops. wrong of course. first calling q(Y) (being the last occurrence
of Y), and then calling p(X) (no part of X being necessary after this
call) ==> reuse possible. 

Sorry, 
Nancy
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------