Here is a recursive action specific

Here is a recursive action specification for moving blocks:

r_put_on(A,B) :-
on(A,B).
r_put_on(A,B) :-
not(on(A,B)),
A == table,
A == B,
clear_off(A), /* N.B. "action" used as precondition */
clear_off(B),
on(A,X),
retract(on(A,X)),
assert(on(A,B)),
assert(move(A,X,B)).

clear_off(table). /* Means there is room on table */
clear_off(A) :- /* Means already clear */
not(on(_X,A)).
clear_off(A) :-
A == table,
on(X,A),
clear_off(X), /* N.B. recursion */
retract(on(X,A)),
assert(on(X,table)),
assert(move(X,A,table)).
A recursive action specification can have the form


action :- preconditions or actions,
retract(affected_old_properties),
assert(new_properties).
Assume again that the original situation holds (and that the previous 'move' clauses have been retracted):


on(a,b).
on(b,c).
on(c,table).
Now,


?- r_put_on(c,a).
yes

?- listing(on), listing(move).

on(a,table).
on(b,table).
on(c,a).

move(a,b,table).
move(b,c,table).
move(c,table,a).

yes
The 'put_on' action has recursively called the 'clear_off' action so that 'c' could be placed on top of 'a'.
Let us now add to the program some clauses so that a list of 'on' properties could be established jointly.


do(Glist) :-
valid(Glist),
do_all(Glist,Glist).

valid(_). /* Temporary. See Exercise 2.19.1 */

do_all([G|R],Allgoals) :- /* already true now */
call(G),
do_all(R,Allgoals),!. /* continue with rest of goals */

do_all([G|_],Allgoals) :- /* must do work to achieve */
achieve(G),
do_all(Allgoals,Allgoals). /* go back and check previous goals */
do_all([],_Allgoals). /* finished */

achieve(on(A,B)) :-
r_put_on(A,B).
The program can now be used by giving a main goal of the form ?- do([...]), where the list contains various on(-,-) subgoal statements (with no variables). Assume that the original starting situation holds again; that is,


on(a,b).
on(b,c),
on(c,table).
Consider the Prolog goal


?- do([on(a,table),on(b,a),on(c,b)]).
yes

?- listing(on), listing(move).
on(a,table).
on(b,a).
on(c,b).

move(a,b,table).
move(b,c,a).
move(c,table,b).

yes
The reader should try the goal and list the resulting program to partially verify that this works the way that we have claimed. This program does nothing special with the plan, other than incorporate it at the end of the program. To generate another plan for the same initial setup, but different goal conditions, one could reload plans.pro first. This inconvenience could be eliminated in several ways, depending on how one intended to use the program (see the exercises for more on this).
Pay particular attention to how the program attempts to satisfy a list of individual goals. The definition of the predicate 'do-all' in the program should be studied carefully. In satisfying a list of individual goals, each goal is worked on from left to right. If an individual goal is already satisfied, then proceed to the next goal. Otherwise satisfy the current goal, but then go back to the beginning of the list to check that the previous goals are still satisfied. Work on them again if they are not still satisfied. Repeatedly do this until all individual goals in the list are satisfied (if possible).
The STRIPS planning system, described in Nilsson (1980), used operators consisting of three components:


Precondition formula, which must be true in order for the
operator to be applicable;

Delete-list, which consists of predicates made false by
the action;

Add-list, which consists of predicates made true by the
action.
The last 'clear_off' clause could be characterized in the STRIPS manner, as follows:


clear_off(A) :
Precondition: A == table, on(X,A), clear_off(X)

Delete-list: on(X,A)

Add-list: on(X,table), move(X,A,table)
Actually this would correspond to the recursive version of STRIPS (RSTRIPS) for the same reason that our program used recursive action specifications. The program presented here uses Prolog as the inference control engine, whereas STRIPS had its own inference and control strategies. A good project would be to read more about STRIPS, and re implement it in Prolog.
The Prolog planning program illustrates several other planning issues. An important thing to notice is that individual goals may not be independent of one another. For example, using the original starting configuration, suppose that we pose the goal


?- do([on(c,b),on(b,a),on(a,table)]).
which is the reverse of the previous goal. This time, the following plan is generated.


move(a,b,table).
move(b,c,table).
move(c,table,b).
move(c,b,table).
move(b,table,a).
move(c,table,b).
Compare this plan with the one previously generated. This plan has redundant moves (like the middle two), and does not otherwise achieve the final conjunction of goals in as efficient