Re: setarg behaviour

On Mon, Jul 29, 2002 at 03:55:00PM +0100, josh singer wrote:
> Hi folks, 
> 
> I had some code which was essentially of the form:
> 
> :- local struct(p(a)).
> 
> make_p(X):-
> 	X = p with [a:0].
> 
> inc_p(X):-
> 	X = p with [a:A],
> 	B is A + 1, 
> 	setarg(a of p, X, B),
> 	printf("p structure:\n", [X]).
> 
> t:-
> 	make_p(Y), 
> 	(
> 		count(I, 1, 10),
> 		param(Y)
> 	do
> 		inc_p(Y), 
> 		printf("p structure:\n", [Y])
> 	).
> 
> Running goal t (using 5.3 build 41 on Solaris) would in some contexts give:
> 
> p structure: p(0)
> p structure: p(0)
> p structure: p(1)
> p structure: p(0)
> p structure: p(2)
> p structure: p(0)
> ...

I suppose this could be buggy optimisation striking again...  It shouldn't
do that.

> "Surprising side effects can occur when you don't know exactly what you are
> doing. In particular, it must be assured by the programmer that [...] the
> old argument was not aliased to some other location."
> 
> It wasn't crystal clear what this meant, but I thought "Aha, X in the
> definition of inc_p/1 gets unified with Y in t/0. This is presumably related
> to aliasing -- X is aliased with Y. So maybe it is undefined whether Y gets
> updated by the setarg or not, sometimes it does, sometimes it doesn't"

No, it means, as Stefano points out, that the arg should not be aliased, and
in this case it is not.

And I'm afraid I'm not comfortable enough to try to give you a definition of
aliasing.  :)  Certainly if A was referred to elsewhere, that would be bad.

> Unfortunately, I don't have my buggy code any more but I can try to
> reconstruct it and reproduce the behaviour if you like. 

That would certainly help us to figure out what was going on and either fix
it or explain it.

Cheers,
Warwick