Re: Found a prob on GNU PROLOG

[Daniel Diaz]

This is a classical example of 'occurs check' problem. Trying to unify U with a
complex term containing U would create an infinite term (for this reason gprolog
loops). Logically, the unification should fail. However, the ISO standard does
not define the behavior of the unfication in presence of such terms since the
detection (called occurs check) is costly. But it defines a predicate
unify_with_occurs_check/2 which must fail in that case (you can then use it).

Quoting Jean Michel LECONTE <address@hidden>:

> I'm using GNU Prolog 1.2.1 so i didn't try what follows on gnu prolog
> 1.2.6
> 
> I start gprolog interpreter
> 
> i ask for the goal U = o(U).
> i have that (i switch the trace on) :
> 
> | ?- U = o(U).
>       1    1  Call: _15=o(_15) ?
>       1    1  Exit: 
> o(o(o(o(o(o(o(o(o(...)))))))))=o(o(o(o(o(o(o(o(o(...))))))))) ?
>  
>                                                                         
>    
> and after it waits a long time and i have to use Ctrl-C to stop it
> 
> 
> now i ask :
> 
> | ?- U = o(U),fail.
>       1    1  Call: _15=o(_15) ?
>       1    1  Exit: 
> o(o(o(o(o(o(o(o(o(...)))))))))=o(o(o(o(o(o(o(o(o(...))))))))) ?
>  
> no  
> 
> 
> Why prolog for my first goal doesn't answer me yes and why it waits a
> big 
> time ???
> 
> 
> _______________________________________________
> Users-prolog mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/users-prolog
> 



===============================================
                 Daniel Diaz
University of Paris 1      INRIA Rocquencourt
75013 Paris FRANCE      78153 Le Chesnay FRANCE
        web: http://pauillac.inria.fr/~diaz
        email: address@hidden
===============================================