Re: setarg behaviour

Dear Josh,

Joachim is away, so you are stuck with our explanations....:-)

I guess the first thing to say is that it is generally a good idea to avoid
setarg/3 if you can, precisely because it has surprising behaviours. setval
and friends generally are better behaved...

Aliasing is difficult to explain without some knowledge of the abstract
machine, and indeed the strange behaviours of setarg/3 are difficult to
explain without knowing about the abstract machine, too. However, if you
created a ground structure from the start, and then change an argument in
the structure using setarg/3, that should be safe. In the code you show,
you do seem to be doing that. However, if, before you call make_p(X), you
do something like:

foo :-
  X = p with [a:A],
  make_p(X), 
  ....

then A is aliased to the argument you are trying to setarg, and here things
can go `unexpected'.


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

a) In simple terms, aliasing means that you have more than one variable that
is referring to the same term. This would happen when you unify two terms
together, and at least one of them is a variable. For example, 
foo :-
  X = Y

would mean X and Y are aliased to each other. 

However,

foo :-
  X = f(A),
  Y = f(B),
  X = Y.

does not mean X and Y are aliased to each other, as they were not variables
when they were unified (however, A and B are aliased to each other). 

b) In strict terms, it is fine if you are certain it is the term whose
argument you want to setarg is aliased, rather than its arguments. However,
this might be difficult to tell unless you know something about how things
are implemented, so it is best avoided as well.


For example, in the following code, the argument of Y is aliased to by A,
and performing setarg on either X or Y might produce `unexpected' results:

 f :-
    X = f(A), Y = f(1), X = Y,
    setarg(1, X, 2), writeln(X-Y-A).
...
[eclipse 3]: f.
f(2) - f(1) - 1

As Warwick said, if you can give us some code which shows the behaviour, we
might be able to explain it better....

Cheers,

Kish