Re: Possible bug in setarg/3

> That is a nice question :-)  It shows one of the many weird behaviours of
> setarg/3.  The first arg/3 call unifies the variable in a(_) with the one in
> b(_,_).  In Prolog, that means there will be a `reference pointer' from one
> to the other.  The direction of this pointer (a->b or b->a) depends on the
> age of the term.  So, if it is a->b and we set arg 1 of a to x, b remains
> a variable.  If it is b->a and we set arg1 of to x, both have the value x.

Thank you! It makes more sense now.

> I must admit I never realised this.  I guess it means you should typically
> ensure that an arg on which you want to do setarg/3 should not be aliased to
> anything else.  In other words, generally do not use variables as initial
> value for args to use with setarg/3.

I guess I didn't realise just how dangerous setarg/3 really is.
Somewhat ironically, I discovered this behaviour while trying to
implement a simple logical (persistent) array module as a wrapper
around setarg/3. Such arrays would be equipped internally with a
manual "trail", so that accessing and updating the "latest version"
could be done in constant time using arg/3 and setarg/3, but accessing
and updating a previous version would still be possible by rolling
back (trailing) the updates that were subsequently applied to that
version.

While I'm at it, I'll ask: does such a library exist already? Do
others consider this worthwhile?

>         Cheers --- Jan

Thanks again!

Michael