Related
I was trying to practice Prolog, as suggested by my TA, I am trying to create the rule append3(A,B,C,D) which means D is the result of the append of A,B and C.
The definition of append(A,B,C) is given
append([],B,B).
append([X|A],B,[X|C]):-append(A,B,C).
So I simply wrote following, which makes sense to me, as the rule for append3
append3(A,B,C,D) :- append(A,B,X),append(X,C,D).
After, I tried some query, such as append3(A,B,C,[1,2,3]). Everything was fine in the beginning, it was giving me the right results. However, at one moment, I pressed ;, it went into an infinite loop trying to search another answer.
I am not really sure why this happens? I suppose that append3(A,B,C,D) is a very basic rule to define. Is there anything that I am missing or that I didn't consider?
How can I fix this problem?
Prolog's execution mechanism is pretty complex compared to command oriented programming languages a.k.a. imperative languages (short form: imps). Your TA has given you an excellent example where you can improve your mastery of Prolog.
First of all, you need to understand the termination behavior of append/3. The best way is via a failure-slice which helps you focus on the part that is relevant to termination. In this case it is:
append([],B,B) :- false.
append([X|A],B,[X|C]):-append(A,B,C), false.
This fragment or failure slice now terminates exactly in all cases where your original definition terminates! And since it is shorter, it makes understanding of termination a bit easier. Of course, this new program will no longer find answers like for append([a],[b],[a,b]) — it will fail in stead. But for termination alone it's perfect.
Now let's go through the arguments one by one:
argument needs to have a non-empty list element and will fail (and terminate) should the argument be [] or any other term. Non-termination may only occur with a partial list (that's a list with a variable instead of [] at the end like [a,b|L]) or just a variable.
argument is just the variable B. There is no way how this B might be different to any term. Thus, B has no influence on termination at all. It is termination neutral.
argument is essentially the same as the first argument. In fact, those arguments look quite symmetrical although they describe different things.
To summarize, if the first or the last argument is a (fully instantiated) list, append/3 will terminate.
Note that I just said if and not iff. After all, the first and third argument are a bit connected to each other via the variable X. Let's ignore that for this analysis.
Now, to a failure slice of your definition.
append3(A,B,C,D) :- append(A,B,X), false, append(X,C,D).
Note that D does no longer occur in the visible part! Therefore, the fourth argument has no influence on termination of this fragment. And since X occurs for the first time, only A has an influence on its termination. Therefore, if A is just a variable (or a partial list), the program will not terminate! No need to look any further. No need to look at screens full of traces.
To fix this for a query like your query append3(A,B,C,[1,2,3])., D has to influence the first goal somewhat.
One possible fix suggested by another answer would be to exchange the goals:
append3(A,B,C,D) :- append(X,C,D), false, append(A,B,X).
Let's look at the variables of append(X,C,D)! C is termination neutral, X occurs for the first time and thus has no influence on termination at all. Only D may make this goal terminate. And thus queries like append3([1],[2],[3], D) will now loop! What a bargain, exchanging non-termination in one case for another!
To make your program work for both cases, the first goal of append/3 must contain both D and at least one of A, B or C. Try to find it yourself! Here is the spoiler:
append3(A, B, C, D) :- append(A, BC, D), append(B, C, BC).
Now the first goal terminates if either A or D is a (fully instantiated) list. The second goal requires either B or BC to be a list. And BC comes from the first goal, which is a list if D is one.
Thus append3(A, B, C, D) terminates_if b(A), b(B) ; (D).
See another answer for more on termination, failure slices, and a technique I have not mentioned here, which is termination inference.
And, note that there are still more cases where the definitions terminate, although they are rather obscure like append([a|_],_,[b|_]) or append3([a|_],_,_,[b|_])) which both fail (and thus terminate) although they only have partial lists. Because of this it's terminates_if and not terminates_iff.
You need to flip the predicates append(A, B, X), append(X, C, D). Since all three variables A, B, and X are unbound in append(A, B, X) prolog tries to satisfy it and then constrain it with append(X, C, D) which will always fail after giving you existing solutions. So it enters an infinite loop.
Try just executing append(A, B, X). all of them unbound. Prolog should show you an infinite sequence of solutions, these fail in the next clause append(X, C, D).
Flip the predicates and you should be fine.
append3(A, B, C, D) :-
append(T, C, D),
append(A, B, T).
I have produced the following code.
list_reverse([],[]).
list_reverse([X],[X]).
list_reverse(Ls,[R|Rs]) :-
last_elem(Ls,R),
without_last_elem(Ls,Next),
list_reverse(Next,Rs).
last_elem([E],E).
last_elem([_|Xs],E) :-
last_elem(Xs,E).
without_last_elem([X,_|[]],[X|[]]).
without_last_elem([X|T0],[X|T1]) :-
without_last_elem(T0,T1).
Swipl:
?- list_reverse([1,2,3],X).
X = [3, 2, 1] ;
false.
This is exactly what I want.
However if I go in the opposite direction I get success, followed by non-termination.
?- list_reverse(X,[1,2,3]).
X = [3, 2, 1] ;
C-c C-cAction (h for help) ? a
abort
% Execution Aborted
What I am struggling to understand is why I first get a correct solution for X. Is my program correct or not?
I am not worried about reversing a list as much as I am about this pattern of getting a correct solution followed by non-termination. It is a pattern I have already come across a few times.
I am [worried] about this pattern of getting a correct solution followed by non-termination.
This is due to the very specific notion of (universal) termination in Prolog. In other programming languages termination is a much simpler beast (still an undecidable beast nevertheless). If, say, a function returns then it terminates (for that case). But in Prolog, producing an answer is not the end as there might be further solutions or just an unproductive loop. In fact, it's best not to consider your query ?- list_reverse(X,[1,2,3]). but rather the following instead.
?- list_reverse(X,[1,2,3]), false.
In this manner all distracting answers are turned off. The only purpose of this query is now either to show termination or non-termination.
After that,
you can either try to follow Prolog's precise execution path but that is as insightful as staring into a car's gearbox when you are lost (the gears caused you to move into the place where you are lost thus they are somehow the cause...). Or, you take a step back, and consider related program fragments (called slices) that share certain properties with your original program. For termination, a failure-slice helps you to better understand what is at stake. In your case consider:
list_reverse([],[]) :- false.
list_reverse([X],[X]) :- false.
list_reverse(Ls,[R|Rs]) :-
last_elem(Ls,R), false,
without_last_elem(Ls,Next),
list_reverse(Next,Rs).
last_elem([E],E) :- false.
last_elem([_|Xs],E) :-
last_elem(Xs,E), false.
?- list_reverse(X,[1,2,3]), false.
Since this failure slice does not terminate, also your original program doesn't terminate! And, it is much easier to reason here in this smaller fragment. If you want to fix the problem, you need to modify something in the visible part. Otherwise you will keep being stuck in a loop.
Note that none of the facts is part of the loop. Thus they are irrelevant for non-termination.
Also note that in list_reverse/2 the variable Rs is never used in the visible part. Thus Rs has no influence on termination! Please note that this is a proof of that property already. Does this mean that the second argument of list_reverse/2 has no influence on termination? What do you think?
The last_elem/2 can keep constructing larger lists, that all should be rejected. But you thus get stuck in an infinite loop.
We can make a function that works with accumulator, and iterates over both the two lists concurrently. That means that once the left or right list is exhausted, no more recursive calls will be made:
reverse(L1, L2) :-
reverse(L1, [], L2, L2).
reverse([], L, L, []).
reverse([H|T], L1, R, [_|T2]) :-
reverse(T, [H|L1], R, T2).
Here the [H|T] and [_|T2] pattern thus both pop the first item of the list, and we only match if both lists are exhausted.
Consider the following Prolog program.
a(X) :- b(_), c(X).
b(1).
b(2).
b(3).
c(1).
Running the query:
a(X).
in SWI-Prolog, we get three results, all X = 1.
Given that we do not care about the anonymous variable, what is preventing SWI-Prolog to return a single result? Why isn't this optimization performed?
Thanks
Well for Prolog the underscore is simply an anonymous variable. So the a/1 predicate is equivalent to:
a(X) :-
b(Y),
c(X).
Now it may look useless to backtrack over the b(Y) clause, since once it is satisfied, the Y is nowhere used, and thus should not have impact on the rest of the program. Furthermore Y has no effect on X so b(Y) should not have the slightest influence on X.
In real Prolog however, there are some things that might have impact:
the b/1 predicate might perform I/O. Say that the predicate is implemented as:
b(a) :-
print(a).
b(a) :-
print(b).
then it will print a in the first branch and b in the second one.
b/1 might raise an exception in a second, third, ... path. In which case we probably want to handle the error;
b/1 might use asserta/1, assertz/1, etc. and alter the program. It might for instance add facts for c/1 such that in the second run c/1 has other results.
A lot of Prolog interpreters have a non-backtrackable store such that the different backtracking paths, can share information with each other.
other coding facilities such that the outcome of b/1 might have impact on c/1.
You can avoid this backtracking over b/1 by using the once/1 meta-predicate. For instance:
a(X) :-
once(b(_)),
c(X).
I want to know how Prolog solves this program:
test(X, Y).
test(X, X):-!, fail.
I googled "negation as failure" but I am confused!
Consider the following example:
father(nick, john).
We use the predicate father(X,Y) to denote that the father of X is Y.
Let's query the database:
?- father(nick,X).
X = john.
?- father(john,Y).
false.
In both cases we asked who is the father of someone (nick, john respectively). In the first case, prolog knew the answer (john) however in the second it didn't and so the answer was false, meaning that john does not have any father. We might expect that, as we gave prolog no information about john's father, it would respond with unknown. That would be an open-world where if something is not known we don't assume that it's false. On the contrary, in the closed world of prolog, if we don't know something, we assume that it's false.
Note that a world where we say that we don't know who the father of john is, based on knowing that anyone must have a father is not an open world; it can be easily modelled in prolog:
data_father(nick, john).
father(X,Y):-
data_father(X,Y) -> true ; true.
On the other hand, in an open world prolog you would write facts and counter facts:
father(nick, john).
not father(adam, X).
And this is negation as failure. However, this is not what happens in your program:
test(X, Y).
test(X, X):-!, fail.
The first clause will always succeed, regardless of the value of the arguments. In fact, exactly because of that, there is no point in naming the arguments and prolog will give you a singleton warning; you can write the clause as test(_, _).
On the other hand, the second clause will always fail. It can fail in two ways: (1) the arguments may be different (2) the arguments are unifiable so prolog moves to the body and then fails.
Precisely because prolog is using a closed world model there is no point of having clauses (without side-effects (but that's considered bad practise anyway)) that always fail. On the contrary, these extra calls cause your program to run slower and use more memory.
It is also worth noting that the cut (!/0) does nothing here since when you reach it there are no more choice points. Consider however this example:
test(X, Y).
test(X, X):-!, fail.
test(X, 42).
?- test(1,42).
true ;
true.
?- test(42,42).
true ;
false.
In both cases prolog will create 3 choice points, one for each clause.
In the first case, Prolog will successfully match the head of the first clause and succeed since there is no body.
Then, it will fail matching the head of the second clause and the body will not be "executed".
Finally, it will match the head of the third clause and succeed since there is no body.
However, on the second case:
Prolog will succeed in matching the head of the first clause and succeed since there is no body.
Then, it will succeed in matching the head of the second clause; the cut will remove all other choice points and then it will fail due to fail.
Therefore, prolog will not try the third clause.
A few words about negation as failure since you mentioned it. Negation as failure is based on the closed world assumption; since we assume that anything that cannot be deduced from the facts we already have is wrong, if we fail to prove something it means that the opposite of it is considered true. For example, consider this:
father(nick, john).
fatherless(X) :- \+ father(X, _).
And
?- fatherless(nick).
false.
?- fatherless(john).
true.
On the contrary, in an open world prolog with the following code:
father(nick, john).
not father(adam, X).
fatherless(X) :- \+ father(X, _).
fatherless/1 would succeed only for adam, fail for nick and return unknown for anything else
the first clause test(X, Y). says that test/2 is unconditionally true, for whatsoever argument pattern.
the second clause test(X, X):-!, fail. says that, when test/2 is called with unifiable first and second argument, there are not more alternative, then fail (note that will fail always, because argument schema is ruling out the instantiation pattern where first argument \= second implicitly).
The operational effect if the same as a logical negation, under 'Closed World Assumption'.
I am trying to understand why Prolog implementations do not behave according to the execution model in textbooks -- for example, the one in the book by Sterling and Shapiro's "The Art of Prolog" (chapter 6, "Pure Prolog", section 6.1, "The Execution Model of Prolog").
The execution model to which I refer is this (page 93 of Sterling & Shapiro):
Input: A goal G and a program P
Output: An instance of G that is a logical consequence of P, or no otherwise
Algorithm:
Initialize resolvent to the goal G
while resolvent not empty:
choose goal A from resolvent
choose renamed clause A' <- B_1, ..., B_n from P
such that A, A' unify with mgu θ
(if no such goal and clause exist, exit the "while" loop)
replace A by B_1, ..., B_n in resolvent
apply θ to resolvent and to G
If resolvent empty, then output G, else output NO
Additionally (page 120 of the same book), Prolog chooses goals (choose goal A) in left-to-right order, and searches clauses (choose renamed clause ...) in the order they show up in the program.
The program below has a definition of not (called n in the program) and one single fact.
n(X) :- X, !, fail.
n(X).
f(a).
If I try to prove n(n(f(X))), it succeeds (according to two textbooks and also on SWI Prolog, GNU Prolog and Yap). But isn't this a bit strange? According to that execution model, which several books expose, this is what I would expect to happen (skipping renaming of variables to keep things simple, since there would be no conflict anyway):
RESOLVENT: n(n(f(Z)))
unification matches X in first clause with n(f(Z)), and replaces the goal with the tail of that clause.
RESOLVENT: n(f(Z)), !, fail.
unification matches again X in the first clause with f(Z), and replaces the first goal in the resolvent with the tail of the clause
RESOLVENT: f(Z), !, fail, !, fail.
unification matches f(Z) -> success! Now this is eliminated from the resolvent.
RESOLVENT: !, fail, !, fail.
And "!, fail, !, fail" should not succeed! After the cut there is a fail. End of story. (And indeed, entering !,fail,!,fail as a query will fail in all Prolog systems that I have access to).
So may I presume that the execution model in textbooks is not precisely what Prolog uses?
edit: changing the first clause to n(X) :- call(X), !, fail makes no difference in all Prologs I tried.
Your program is not a pure Prolog program, since it contains a !/0 in n/1. You may ask yourself the simpler question: With your definitions, why does the query ?- n(f(X)). fail although there clearly is a fact n(X) in your program, meaning that n(X) is true for every X, and should therefore hold in particular for f(X) as well? This is because the program's clauses can no longer be considered in isolation due to the usage of !/0, and the execution model for pure Prolog cannot be used. A more modern and pure alternative for such impure predicates are often constraints, for example dif/2, with which you can constrain a variable to be distinct from a term.
The caption below does tell you what this particular algorithm is about:
Figure 4.2 An abstract interpreter for logic programs
Also, its description reads:
Output: An instance of G that is a logical consequence of P, or no otherwise.
That is, the algorithm in 4.2 only shows you how to compute a logical consequence for logic programs. It only gives you an idea for how Prolog actually works. And in particular cannot explain the !. Also, the algorithm in 4.2 is only able to explain how one solution ("consequence") is found, but Prolog tries to find all of them in a systematic manner called chronological backtracking. The cut interferes with chronological backtracking in a very particular manner which cannot be explained at the level of this algorithm.
You wrote:
Additionally (page 120 of the same book), Prolog chooses goals (choose goal A) in left-to-right order, and searches clauses (choose renamed clause ...) in the order they show up in the program.
That misses one important point which you can read on page 120:
Prolog's execution mechanism is obtained from the abstract interpreter by choosing the leftmost goal ... and replacing the non-deterministic choice of a clause by sequential search for a unifiable clause and backtracking.
So it is this little addition "and backtracking" which makes things more complex. You cannot see this in the abstract algorithm.
Here is a tiny example to show that backtracking is not explicitly handled in the algorithm.
p :-
q(X),
r(X).
q(1).
q(2).
r(2).
We would start with p which is rewritten to q(X), r(X) (there is no other way to continue).
Then, q(X) is selected, and θ = {X = 1}. So we have r(1) as the resolvent. But now, we do not have any matching clause, so we "exit the while loop" and answer no.
But wait, there is a solution! So how do we get it? When q(X) was selected, there was also another option for θ, i.e. θ = {X = 2}. The algorithm itself is not explicit about the mechanism to perform this operation. It only says: If you make the right choice everywhere, you will find an answer. To get a real algorithm out of that abstract one, we thus need some mechanism to do this.
When you reach the last step:
RESOLVENT: !, fail, !, fail
the cut ! here means, "erase everything". So the resolvent becomes empty. (this is faking it of course, but is close enough). cuts have no meaning at all here, the first fail says to flip the decision, and 2nd fail to flip it back. Now resolvent is empty - the decision was "YES", and remains so, twice flipped. (this is also faking it ... the "flipping" only makes sense in the presence of backtracking).
You can't of course place a cut ! on the list of goals in the resolvent, as it is not just one of the goals to fulfill. It has an operational meaning, it normally says "stop trying other choices" but this interpreter keeps no track of any choices (it "as if" makes all the choices at once). fail is not just a goal to fulfill too, it says "where you've succeeded say that you didn't, and vice versa".
So may I presume that the execution model in textbooks is not precisely what Prolog uses?
yes of course, the real Prologs have cut and fail unlike the abstract interpreter that you referred to. That interpreter has no explicit backtracking and instead has multiple successes by magic (its choice is inherently non-deterministic as if all the choices are made at once, in parallel - real Prologs only emulate that through sequential execution with explicit backtracking, to which the cut is referring - it simply has no meaning otherwise).
I think you got it almost right. The problem is here:
RESOLVENT: !, fail, !, fail.
The first ! and fail are from the second time that the first clause was matched. The other two are from the first time.
RESOLVENT: ![2], fail[2], ![1], fail[1].
The cut and fail have effect on the clause that is being processed -- NOT on the clause that "called" it. If you work through the steps again, but using these annotations, you'll get the right result.
![2], fail[2] makes the second call to n fail without backtracking. But the other call (the first) can still backtrack -- and it will:
RESOLVENT: n(_)
And the result is "yes".
This shows that Prolog keeps information about backtracking using a stack discipline. You may be interested in the the virtual machine that is used as a model for Prolog implementations. It is quite more complex than the execution model you mentioned, but the translation of Prolog into the VM will give you a much more accurate understanding of how Prolog works. This is the Warren Abstract Machine (WAM). The tutorial by Hasan Aït-Kaci is the best explanation you'll find for it (and it explains the cut, which if I remember correctly was absent from the original WAM description). If you are not used to abstract theoretical texts, you may try reading the text by Peter van Roy first: "1983-1993: the wonder years of sequential Prolog implementation". This article is clear and basically goes through the history of Prolog implementations, but giving special attention to the WAM. However, it does not show how the cut is implemented. If you carefully read it, however, you may be able to pick up Hasan's tutorial and read the section in which he implements the cut.
You have an extra level of nesting in your test goal:
n(n(f(X))
instead of:
n(f(X))
And indeed, if we try that, it works as expected:
$ prolog
GNU Prolog 1.3.0
By Daniel Diaz
Copyright (C) 1999-2007 Daniel Diaz
| ?- [user].
compiling user for byte code...
n(X) :- call(X), !, fail.
n(_X).
f(a).
user compiled, 4 lines read - 484 bytes written, 30441 ms
yes
| ?- f(a).
yes
| ?- n(f(a)).
no
| ?- n(f(42)).
yes
| ?- n(n(f(X))).
yes
| ?- n(f(X)).
no
| ?- halt.
So your understanding of Prolog is correct, your test case was not!
Updated
Showing the effects of negations of negations:
$ prolog
GNU Prolog 1.3.0
By Daniel Diaz
Copyright (C) 1999-2007 Daniel Diaz
| ?- [user].
compiling user for byte code...
n(X) :- format( "Resolving n/1 with ~q\n", [X] ), call(X), !, fail.
n(_X).
f(a) :- format( "Resolving f(a)\n", [] ).
user compiled, 4 lines read - 2504 bytes written, 42137 ms
(4 ms) yes
| ?- n(f(a)).
Resolving n/1 with f(a)
Resolving f(a)
no
| ?- n(n(f(a))).
Resolving n/1 with n(f(a))
Resolving n/1 with f(a)
Resolving f(a)
yes
| ?- n(n(n(f(a)))).
Resolving n/1 with n(n(f(a)))
Resolving n/1 with n(f(a))
Resolving n/1 with f(a)
Resolving f(a)
no
| ?- n(n(n(n(f(a))))).
Resolving n/1 with n(n(n(f(a))))
Resolving n/1 with n(n(f(a)))
Resolving n/1 with n(f(a))
Resolving n/1 with f(a)
Resolving f(a)
yes
| ?- halt.
While mat is right in that your program is not pure prolog (and this is relevant as the title of the chapter is Pure Prolog), not only since you use a cut but also since you write predicates that handle other predicates (pure prolog is a subset of first order logic) this is not the main issue; you are just missing backtracking
While you indeed have a cut, this will not be reached until goal n(f(X)) succeeds. However, as you know, this will fail and therefore prolog will backtrack and match the second clause.
I do not see how that would contradict with the model described in 6.1 (and would find it hard to believe that other books would describe a model where the execution would continue after failing and thus allow for the cut to prune the other solutions). In any case, I find that jumping to the conclusion that "Prolog implementations do no behave according to the execution model in textbooks" is quite similar to "there is a bug to the compiler", especially since the "counter-example" behaves as it should (not(not(true)) should be true)