how to rename variables?

Hello.

I wonder if I can find in Prolog a build-in predicate
that allow me to rename all the variables in a list
of terms in order to make these terms to don't
share variables.

Something that behaves like this:

?- rename([X+Y, f(X,g(X))], OutputList).

OutputList = [X1+X2, f(X3,g(X3))]

I know the predicate gensym, that associates
an unique atom to every variable of a list,
but my problem is slightly different...

Thankyou.
Giovanni

Giovanni Gherdovich wrote:
> Hello.
>
> I wonder if I can find in Prolog a build-in predicate
> that allow me to rename all the variables in a list
> of terms in order to make these terms to don't
> share variables.
>
> Something that behaves like this:
>
> ?- rename([X+Y, f(X,g(X))], OutputList).
>
> OutputList = [X1+X2, f(X3,g(X3))]

Try copy_term/2.

Cheers

Bart Demoen

Dear Mr. Demoen,

> Try copy_term/2.

Yes, this is the right predicate;
thankyou.

| ?- copy_term(X+Y, OutputTerm).
|
| X = _G180
| Y = _G181
| OutputTerm = _G272+_G273 ;
|
| No
| ?- copy_term(f(X,X), OutputTerm).
|
| X = _G180
| OutputTerm = f(_G257, _G257) ;
|
| No

Regards,
Giovanni

On Aug 25, 5:43 am, Giovanni Gherdovich
<gherdov...@students.math.unifi.it> wrote:
> Dear Mr. Demoen,
> 
>
> Yes, this is the right predicate;
> thankyou.
>
> | ?- copy_term(X+Y, OutputTerm).
> |
> | X = _G180
> | Y = _G181
> | OutputTerm = _G272+_G273 ;
> |
> | No
> | ?- copy_term(f(X,X), OutputTerm).
> |
> | X = _G180
> | OutputTerm = f(_G257, _G257) ;
> |
> | No
>
> Regards,
> Giovanni

Hi, Giovanni:


I believe you have noticed that, to get the result
described in your original post, where the X in
the term X+Y first listed is not bound to the same
new variable as the X in the term f(X,X), you will
need to apply copy_term/2 to each entry in the list
of terms.

| ?- copy_term([X+Y,f(X,g(X))],OutTerm).
|
| X = _G187
| Y = _G188
| OutTerm = [_G300+_G301, f(_G300, g(_G300))] ;

As the above illustrates, passing the entire list
at once to copy_term creates a coherent mapping of
the variables, X going from _G187 to _G300 in all
appearances, while your example had the X in the
first term coming "unglued" from the X's in the
second term of the list.

regards, chip

Chip Eastham <hardmath@gmail.com> writes:

>  you will need to apply copy_term/2 to each entry in the list

You can also use:

%?- Ls = [X+Y, f(X,g(X))], findall(C, member(C, Ls), Cs).
%@ Cs = [_G317+_G318, f(_G306, g(_G306))]

And copy_term(T, C) can also be obtained by: findall(T, T==T, [C]).

--
comp.lang.prolog FAQ: http://www.logic.at/prolog/faq/

Jan Wielemaker <jan@nospam.ct.xs4all.nl> writes:

> True, but copy_term/2 is more efficient and the detailed semantics

Indeed; however, the "term copying" property of findall is worth
knowing since it can be used to define the entire evaluation strategy
of pure Prolog in a single line of semi-deterministic Prolog code:

step([A|As0], As) :- findall(Gs-G, (A=[G0|Rest]-G,ld(G0,Gs,Rest)), As, As0).

It assumes clauses in the form of list differences, like:

ld(natnum(0), Gs, Gs).
ld(natnum(s(X)), [natnum(X)|Gs], Gs).

The interface predicates for the meta-interpreter could be:

mi(G0) :- mi([[G0]-G0], G0).

mi([[]-G|_], G).
mi(As0, G) :- step(As0, As1), mi(As1, G).

Example query:

%?- mi(natnum(X)).
%@ X = 0 ;
%@ X = s(0) ;
%@ X = s(s(0)) ;
%@ X = s(s(s(0))) a
%@ Yes

Luckily, the CVS version of SWI Prolog already includes findall/4, the
list difference version of findall/3. Otherwise, the meta-interpreter
would - wastefully - have taken 2 lines. :-)

--
comp.lang.prolog FAQ: http://www.logic.at/prolog/faq/

On Sun, 26 Aug 2007 23:34:06 +0200, Markus Triska wrote:


> Indeed; however, the "term copying" property of findall is worth
> knowing since it can be used to define the entire evaluation strategy
> of pure Prolog in a single line of semi-deterministic Prolog code:
>
>   step([A|As0], As) :- findall(Gs-G, (A=[G0|Rest]-G,ld(G0,Gs,Rest)), As, As0).[/co
lor]

I had never considered the question
what would be the worst reason why I would like to know about
the copying semantics of findall/3 ?

I now know the answer - I am so happy !

Reminds a bit of 42.

Bart Demoen

bart demoen <bmd@cs.kuleuven.be> writes:

> I had never considered the question
> 	what would be the worst reason why I would like to know about
> 	the copying semantics of findall/3 ?
>
> I now know the answer - I am so happy !

Nice to hear - and what would it be? (We already covered findall/*4*.)

On Mon, 27 Aug 2007 22:55:46 +0200, Markus Triska wrote:

> bart demoen <bmd@cs.kuleuven.be> writes:
> 
 
>
> Nice to hear - and what would it be? (We already covered findall/*4*.)

Maybe you need to do some homework: the copying semantics of
findall/x is the same for x = 3 and 4

Cheers

Bart Demoen

ps. findall/4 might impress people as the most recent version of sliced
bread (and I surely agree that it is useful, very useful  indeed); it was
in BIM-Prolog since ... always; I should consult my old manuals, but the
MasterProlog version of BIM-Prolog of 15-Aug-1999 (still running here in
Leuven, and used on a daily basis) has findall/4; also SICStus has it, and
Yap and B-Prolog (with the last two args switched) - XSB, ECLiPSe and
GNU-Prolog seem not to know about it, but I might have missed their local
variant of it - it isn't ISO after all

cheers once more :-)

On 2007-08-27, bart demoen <bmd@cs.kuleuven.be> wrote:
> On Mon, 27 Aug 2007 22:55:46 +0200, Markus Triska wrote:
> 
> 
>
> Maybe you need to do some homework: the copying semantics of
> findall/x is the same for x = 3 and 4
>
> Cheers
>
> Bart Demoen
>
> ps. findall/4 might impress people as the most recent version of sliced
> bread (and I surely agree that it is useful, very useful  indeed); it was
> in BIM-Prolog since ... always; I should consult my old manuals, but the
> MasterProlog version of BIM-Prolog of 15-Aug-1999 (still running here in
> Leuven, and used on a daily basis) has findall/4; also SICStus has it, and
> Yap and B-Prolog (with the last two args switched) - XSB, ECLiPSe and
> GNU-Prolog seem not to know about it, but I might have missed their local
> variant of it - it isn't ISO after all

I added findall/4 on request and value compatibility a lot, but I still
wonder what is wrong with:

..
findall(Gen, Goal, Sols),
append(Sols, Tail, Result),
..

Efficiencywise findall/3 is a joke anyway, and the append doesn't make
it significantly worse. I consider findall/3 as a need-to-have, but
otherwise as an undesirable beast like the cut. Its the least unelegant
way to save data over backtracking, but that is about it.  Think of
examples like

count_solutions(Goal, Count) :-
findall(x, Goal, Xs),
length(Xs, Count).

Who will consider creating a list of Xs just to count solutions? Even if
we are looking for distinct solutions, sensible progammers make a table
and add only new solutions to this table. They maintain the size of the
table, request it at the end and drop the table. Using setof/3 or
findall/3+sort/2 for this task makes more sense than the above counting
example, but it is still a second-best solution.

As said, besides these considerations semantics get unclear if we have
mutable terms or constraints in the picture.

Cheers --- Jan