Say I have the following list of literals and a cut in my query:
?- c(X), d(X), e(X), !.
if X=1 evaluates all the literals to true, does the cut, !, predicate, at the end, get called anyway or can the whole thing backtrack?
From my own experience it seems like it can't backtrack, which implies the cut predicate is called even after true or yes has been found, is that accurate?
Yes; although I'm not sure what you are thinking of when you say
get called anyway
even though its name is an exclamation mark instead of a word and it does something outside normal logic, cut is "just another predicate" ("literal") in the sense that it gets called if execution gets to it. If c(X) holds for the current value of X then d(X) is called. If that holds then e(X) is called. If that holds then ! is called.
Using some low effort proxies for c d e:
?- member(X, [1,2,3,4,5]), write(X), X>2, write(X).
?- member(X, [1,2,3,4,5]), write(X), X>2, write(X), !.
The first line, member chooses a value for X and binds X=1, marks a choicepoint, writes 1, fails at X>2, backtracks to the choicepoint, rebinds X=2, tries again, fails again, backtracks to the choicepoint again, rebinds X=3, now all three succeed; Prolog gives you X = 3 as a solution and the choicepoint is still there so it waits for you to ask for more solutions or cancel. If you prompt for more, it backtracks to the choicepoint, binds X=4, tries again.
The second line does the same initially, but once it gets to X=3 the cut is called, the choicepoint from member() is removed and Prolog gives you X = 3 and finishes, no prompts. It has found a solution and pruned (cut) the search tree so it has not, and will not, explore for all possible solutions.
Since a Prolog program can have a lot of choicepoints happening, one "cut" will not remove all of them; exactly which ones are removed by any given ! is in #brebs' link.
Related
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.
I am just starting to learn Prolog and I played around with it. Now I got to a point where I´m stuck. The program i wrote gets into an infinite loop when I ask for
?- q(b).
and I don´t understand why it does that. It would be nice if someone could explain it to me.
p(a).
p(b).
q(Y) :- r(X), r(Y).
r(X) :- r(f(X)).
r(a) :- p(c).
r(a) :- p(a).
r(b) :- p(b).
As said in the comment, the loop is caused by r/1. To show why, yust type ?- trace, q(b). Look at the trace (ignore by now the singleton warning):
Call:q(b)
Call:r(_4244)
Call:r(f(_4162))
Call:r(f(f(_4162)))
Call:r(f(f(f(_4162))))
Call:r(f(f(f(f(_4162)))))
Call:r(f(f(f(f(f(_4162))))))
Call:r(f(f(f(f(f(f(_4162)))))))
Call:r(f(f(f(f(f(f(f(_4162))))))))
Now you can see that it try to derives r/1 entering a loop. You can see also this question to have a more in depth explaination.
Notice that in prolog, the order of the clauses matters. Just try to put the line r(X) :- r(f(X)). to the bottom of your program. Now try ?- q(b). On the first answer you get true because prolog unifies X with a and Y with b before entering in a loop.
Another way to identify reasons for non-termination is to reduce the number of inferences your program will execute by adding goals false into your program:
q(Y) :- r(X), false, r(Y).
r(X) :- r(f(X)), false.
r(a) :- false, p(c).
r(a) :- false, p(a).
r(b) :- false, p(b).
?- q(Y).
loops.
Since this program is still looping, you will need to modify something in the visible part. Note how many things have been removed entirely! No matter how p/1 is defined, this problem will persist.
If you look at q/1 closely, you see one of the problems:
q(Y) :- r(X), false, r(Y).
The variable Y is not used in the visible part at all. The X appears just once. Thus, r(X) will be the most general query possible and thus it will have the worst termination property possible (that depends on the definition of r/1, indeed). In any case, the argument of q/1 has no influence on termination!
There is another property to conclude: The order of clauses does not have any influence on the termination property! You can see this easily: No matter where the clauses that have been removed entirely with false appear, they can be removed.
For more, see failure-slice.
I'm trying to further my understanding of Prolog, and how it handles unification. In this case, how it handles unification with lists.
This is my knowledgebase;
member(X, [X|_]).
member(X, [_|T]):- member(X, T).
If I'm understanding the process correctly. If member(X, [X|_]) is not true, then it moves into the recursive rule, and if X is in list T, then [_|T] is unified with T.
So what happens to the anonymous variable in my recursive predicate? Does it get discarded? I'm having difficulty understanding the exact unification process with lists, as [_|T] is two variables, rather than one. I'm just trying to figure out how the unification process works precisely with lists.
Assume that _ is Y
member(X, [Y|T]):- member(X, T).
Then this is True regardless Y. Now you are "returning" member(X, T). In other words, you are discarding Y and "returning" member(X, T).
_ means, whatever it is, ignore that variable.
The _ is just like any other variable, except that each one you see is
treated as a different variable and Prolog won't show you what it
unifies with. There's no special behavior there; if it confuses you
about the behavior, just invent a completely new variable and put it
in there to see what it does.
In your case, your function check if a given element exists on a list, so, you take first element of the list, check if is equal, if not, you discard that element and moves on.
I think your primary question of how lists are represented as variables has been adequately answered, but I sense there are some other aspects to Prolog that need clarification.
To understand Prolog predicates and clauses, it's a good idea not to think of them as "functions" that "return" things, even metaphorically. It can lead you down the dark path of imperative thinking in Prolog. :)
In considering the predicate:
(1) member(X, [X|_]).
(2) member(X, [_|T]) :- member(X, T).
Think of member/2 as a relation which describes when element X is a member of the list L, and the clauses are the rules for determining when it is true.
I'll assume that you already know about how lists are represented in Prolog based upon other answers (e.g., Will Ness' detailed answer).
The first clause says:
(1) X is a member of [X|_] regardless of what the tail of the list [X|_] is
In that notation, the variable _ represents the tail of list [X|_] and X represents the first element of that list. It's trivially true that X is a member of this list, so member(X, [X|_]). is a fact. It's true regardless of what the tail of the list is, so we just use _ (an anonymous variable) since this rule doesn't need the information. Prolog doesn't technically "throw the value away" but the programmer throws it away because the programmer isn't using it. If we had, instead, said, member(X, [X|T]). that would work fine, but we're not using T. Prolog might instantiate it, but it wouldn't be used. It's like assigning x = 3 in C but not using it's value. In this case, Prolog will indicate a warning about a "singleton" variable. Watch for those, because it often means you misspelled something or forgot something. :)
The next rule is recursive. It says:
(2) X is a member of list [_|T] if X is a member of the tail (T) of that list, regardless of what the first element of the list is
Here we're considering the less trivial case where the first element in the list may not be a match to X, so the truth value of member(X, L) depends, in this rule, upon the truth value of member(X, T) where T is the tail (everything but the first element) of L. The rule does not unify member(X, [_|T]) with member(X, T), so it does not unify T with [_|T] as you might suppose. The :- operator defines a rule or implication (note the if in the rule description). [N.B., If you were to unify these terms, it would be done with with the unification operator, =/2: member(X, [_|T]) = member(X, T)].
On the recursive query member(X, T), Prolog goes back to the top, the first rule, and attempts to unify the first argument X with the head of the second argument (which is the original list minus its first element, or head) and, if it doesn't match, goes to rule #2 again, continually checking the tail as well, until it can unify. If it gets to the point where the tail is empty ([]) and hasn't been able to unify X with any elements, the predicate fails because there are no facts or rules that match member(X, []). However, if it does unify X with an element, it succeeds (it does not "return a value* in the sense that a function would in other languages) and reveals the values of any variables it instantiated in the arguments in the process, or simply will succeed if all the arguments passed are already instantiated. If there are more rules to check after succeeding (there was what's called a choice point), it will (if you tell it to) go back and check for more solutions and, if it finds them, display them as well. Or display no or false if there are no more.
Looking at an example query, is b a member of [a,b,c]?
member(b, [a,b,c]).
Prolog will first try to unify the query with a fact or the head of a predicate. The first one it finds is:
member(X, [X|_]).
In attempting to unify, X = b, but [a,b,c] (or, [a|[b,c]] in the head-tail notation) doesn't unify with [b|_](note the head elementsaandb` mismatch). Prolog then moves on to the next clause:
member(X, [_|T]) :- member(X, T).
In unifying member(b, [a,b,c]) with the head, it comes up with:
member(b, [_|[b,c]]) :- member(b, [b,c]).
It now has the recursive query to chase down: member(b, [b,c]). Since it's a new query, it starts at the top again and attempts to unify this with member(X, [X|_]). Now, it's successful, because member(b, [b,c]) (or, member(b, [b|[c]])) matches this pattern: member(b, [b|_]).
Therefore, the member(b, [a,b,c]). succeeds and Prolog will return "true". However, it's not done yet because it left what's called a choice point. Even though it matched member(b, [b,c]) with the first clause, it will still want to go back and find more cases that make it succeed, and there's still another clause to pursue. So, Prolog will go back and try member(b, [b,c]) against the second clause, matching member(b, [b|[c]]) to member(b, [_|[c]]) and doing another recursive query, member(b, [c]) and so on until it ultimately fails to find another solution. This is why the query looks something like this:
| ?- member(b, [a,b,c]).
true ? ;
no
| ?-
It first succeeds, but then we ask for more (with ;) and it then fails (no). This confuses some Prolog beginners, but it's because we've asked Prolog to get another solution, and it said there are none.
Because Prolog continues to try to find solutions (upon request), you can also use a variable in the query:
member(E, [a,b,c]).
This query runs the same way as the prior example, but now I have a variable as the first argument. Prolog will successfully match this to the first clause: member(E, [a,b,c]) unifies with member(X, [X|_]) via E = a. So you'll see something like:
| ?- member(E, [a,b,c]).
E = a ?
If we now ask for more solutions with ;, Prolog goes back and attempts the second clause, unifying member(E, [a|[b,c]]) with member(X, [_|T]) yielding _ = a (which is ignored in the predicate) and T = [b,c]. It then recursively queries, member(E, [b,c]) and, since it's a new query, goes back to the top and matches member(X, [X|_]) again, this time with E = b. So we see:
| ?- member(E, [a,b,c]).
E = a ? ;
E = b ?
And so on. member(E, [a,b,c]) will find all the values of E which make member(E, [a,b,c]) true and then finally fail after exhausting all the elements of [a,b,c]).
[A|B] represents a list where A is the Head element and B is the whole rest list.
So to explain you the algorithm shortly:
Clause: If X is the first element of the list the predicate succeeds.
Clause: If that's not the case, we try to find X in the tail of the list. Therefore, we call member recursively but instead of passing the whole list we now pass the list EXCEPT the head element. In other words, we walk through the list step by step always looking at the head element first. If that is not our element, we dig further.
Think of the anonymous variable _ just as a variable you do not need later. The algorithm would also work, if you replaced _ by a capital letter, however it would give you a warning that you named a variable that you never use.
A list is just a compound term with the '.' functor:
1 ?- [_|T] = .(_,T).
true.
2 ?- [_|T] =.. X.
X = ['.', _G2393, T].
The usual process of structural unification of compound terms apply:
3 ?- [A|T] = .(B,R).
A = B,
T = R.
[A|T] is really .(A,T) so the functors (.) and the arities (both terms are binary, of arity 2) match, so the respective constituents are matched as well.
Yes, the anonymous variable _ is ignored for the purposes of reporting the unification results. Otherwise it is just a fresh uniquely named variable.
it moves into the recursive rule, and if X is in list T, then [_|T] is unified with T.
Not quite. The unification happens before the "moving on", as part of the clause selection. To unify a list L with [_|T] is to select its "tail" and have T referring to it. E.g.
4 ?- L = [1,2,3], L = [_|T].
L = [1, 2, 3],
T = [2, 3].
(_ is 1 but is not reported).
My lecturer gave us this sample program to look at the code, while I understood the recursive function on a whole the was this one line I couldn't quite grasp the meaning of
all_different([H | T]) :- member(H, T), !, fail.
extracted from the recursive function:
all_different([H | T]) :- member(H, T), !, fail.
all_different([_ | T]) :- all_different(T).
all_different([_]).
all I understood about it is that it splits a list into a Head H and a Tail T and checks if H is contained in T...My question is, what is it that "!" and "fail" do?
These things are pretty fundamental to Prolog.
fail is essential. It forces Prolog to consider the current branch a failure and initiates backtracking.
The ! is called "the cut." It commits Prolog to the current branch. Or, it prunes the trail of choice points under the current rule.
Taken in conjunction, in Prolog-ese, this says "If the head of the list is present in the tail of the list, there is no need to look for any additional answers, and fail." Thus, if any element of the list is present in the remainder of the list, you'll get an immediate failure with no chance of backtracking. This isn't actually all that dire, it just means that Prolog won't waste any more time trying to figure out if the list is "all_different." Backtracking will resume at the call site normally.
It's important that these go in this order. If you tried to cut after the fail, you'd never make it to the cut, because backtracking would already have begun. If you omit the cut, the predicate will return true if there is any sublist of the list which satisfies the property. This is guaranteed to be the case for any non-empty list by the last clause, which asserts that a list with one element satisfies the property. If you omit the fail, you're just going to get one success for each element of the list that is in a sublist, plus one for the tail. I encourage you to try playing around with the predicate, making these changes and seeing the effects, because it will go a long way to illustrating the purpose of the cut and fail.
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'.