🚀 go-pugleaf

In article <1162@cluster.cs.su.oz> andrewt@cluster.cs.su.oz (Andrew Taylor) writes:
>Here is a hint, consider this predicate:
>
>	a(X) :- write(first - X), b(X).
>	a(X) :- write(second - X), c(X).
>
>You'd expect that if backtracking occurred the second value of X written out
>would be the same as the first value of X written out. This is not so
>with your version of setarg. This is disasterous for either compiler
>analysis or human understanding of programs.
>
>Even when always undone on backtracking setarg is still a disaster so
>maybe all you have done is turn a disaster into a catastrophe.

1) I *agree* *any* form of destructive assignment is a bad idea
from the point of view of declarative (read as ``any'') reading
of a program. I am not trying to advocate it.

2) By using a cut after setarg you *lose* the backtrack
point so the modification becomes ``permanent'', which
was the whole point in my previous message. 

3) If, in your example b/1 uses setarg/3 to modify (part of 
whatever) X then, unless it issues a cut the value of X used by the second 
clause of a/1 *will* be the same as the first since backtracking had to occur 
(and, as you acknowledge backtracking thru setarg/3 restores the original 
argument).

On the other hand, if a cut is executed somewhere subsequent to
setarg/3 (dynamically inside b/1 somewhere) then, presumably,
the idea *was* that the change to X become ``permanent''.

4) see (1).

-Kym Horsell