setarg behaviour

From: josh singer <josh.singer_at_parc-technologies.com>
Date: Mon 29 Jul 2002 02:55:00 PM GMT
Message-ID: <3E899FAFBF56D611B6A500508B9A9DA203E5F0@LON-SRV2>
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)
...

In other contexts, I'd get

p structure: p(0)
p structure: p(0)
p structure: p(1)
p structure: p(1)
p structure: p(2)
p structure: p(2)
...

I scratched my head a bit and went back to the setarg documentation, and
noticed the following caveat:

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

I replaced the code with something essentially the same as the following:

make_p(X):-
	X = p with [a:f(0)].

inc_p(X):-
	X = p with [a:F],
	F = f(A),
	B is A + 1, 
	setarg(1, F, B),
	printf("p structure:\n", [X]).

i.e. introducing the intermediate functor f. My reasoning being that F never
gets unified with anything outside of inc_p/1. 

This works fine. However, Stefano pointed out that the setarg docs (a) don't
define aliasing and (b) require that the *Arg* of setarg/3 not be aliased,
not the Term. 

So my questions are (a) what exactly is meant by aliasing, and (b) is it
also the case that the Term should not be "aliased". 

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

cheers, 

josh

Developer, Parc Technologies Limited
josh.singer@parc-technologies.com
http://www.parc-technologies.com

This e-mail message is for the sole use of the intended recipient(s)
-its contents are the property of Parc Technologies Limited (or its
licensors) and are confidential. Please do not copy, review, use
(except for the intended purposes), disclose or distribute the e-mail
or its contents (or allow anyone else to do so) without our prior
permission. Parc Technologies Limited does not guarantee that this
e-mail has not been intercepted and amended nor that it is
virus-free. You should carry out your own virus checks before opening
any attachment.  Any opinions expressed in this e-mail message are
those of the author and not necessarily Parc Technologies Limited.
Received on Mon Jul 29 15:53:27 2002

This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:08:17 PM GMT GMT