?so /usr/aaron/para.rno
?fo 'Aaron Sloman'' \*(DY'
?he 'BLOCKS''Page %  '
.mh
SOME BLOCKS-WORLD PROGRAMS USING THE DATABASE
==== ============ ======== ===== === ========
.hm
This is an introduction to the design of programs which make plans and
can represent the process of excuting them. It makes use of the
POP11 DATABASE package. For details see the DATABASE demo.

Apart from its own interest, the ideas presented here should 
help you understand what Winograd's program does after it has analysed
an English sentence.

Consider a very simple blocks world (much simpler than Winograd's).

 	 ----			   HH
 	| B2 |			   HH
 	|blue|			   HH
    ------------		   HH    --------
   |		|		   HH   |	 |
   |		|		HHHHHHHH|	 |
   |	B1	| ----		H ---- H|   B5	 |
   |	red  	|| B3 |		H| B4 |H|  blue	 |
   |		||blue|		 | red| |	 |
 ======================        ==========================
 	HERE				THERE

Each block has:
 	a SIZE (BIG or SMALL)
 	a COLOUR(RED or BLUE)
 	a LOCATION (HERE or THERE)
 	and is ON something (a TABLE or another block)
.br
There is a HAND, which has a location, either HERE or THERE,
and it may be grasping one of the blocks.
.mh
Using the database to represent the world
----- --- -------- -- --------- --- -----
.hm
Facts about the world can be represented as "patterns" stored in the
database. For instance, patterns like:
 	: [B1 ISA BLOCK]
 	: [B2 ISA BLOCK]
 	: [COLOUR B3 BLUE]
 	: [SIZE B4 SMALL]
 	: [LOCATION B1 HERE]
 	: [ON B1 TABLE]
 	: [ON B2 B1]
 	: [LOCATION HAND THERE]
 	: [GRASPING HAND B4]
 	: etc.

Instead of explicitly using ADD to store all these patterns, we can
define functions using ADD which will store several patterns
at once.

For example, to put into the database a collection of patterns like:
 	: [COLOUR B1 RED]
 	: [COLOUR B2 RED]
.br
It would be useful to be able to type something like:
 	: PUTPROPS([B1 B2], "COLOUR", "RED");
.br
instead of adding each pattern separately.
.br
We could use a function defined as follows:
 	: FUNCTION PUTPROPS(LIST, PROP, VALUE);
 	:	IF	LIST /=[]
 	:	THEN	ADD([%PROP, HD(LIST), VALUE%]
 	:		PUTPROPS(TL(LIST),....)
 	:	CLOSE
 	: END;
.br
How should the dots be replaced?
.br
Then
 	: PUTPROPS([B4 B5 HAND], "LOCATION", "THERE");
.br
will store information about locations of several objects.

So
 	"B4 B5 and the HAND all have location here"
.br
could be translated by a language-understanding program into
the above instruction, i.e. into POP11,
just as the compiler translates POP11 into machine code.
After translating, the language understander might execute the POP11.
.br
(Do you think our understanding of sentences ever has two such stages?
See Davies and Isard, "Utterances as programs" in MI7.)

Similarly, we can give commands like:
 	: PUTPROPS([B1 B3 B4 B5], "ON", "TABLE");
 	: PUTPROPS([B1 B5], "SIZE", "BIG");
 	: etc.
.br
How can changes in the world be represented?
.mh
Representing actions and processes
----------------------------------
.hm
A program controlling a robot needs to be able to do more than represent
static situations. It must also represent actions, like
grasping something, ungrasping and moving the hand.

It will need to make use of such facts as that, if the hand is THERE it
cannot grasp a block which is HERE, and that if the hand moves whilst
grasping something, the thing grasped will move too.

In planning sequences of actions to achieve goals of various sorts, for example
"Put B3 on B5" the program may represent hypothetical processes. It can do
this by alterations to the database. Changes can be represented by using
the functions ADD and REMOVE. We shall use ADD and REMOVE to define functions
which represent quite complex changes in the world (for example complex actions).
.sp2
.tp4
Constraints
.br
-----------
.br
Notice that there is a possibility of inconsistency, for example if
something is said to be ON a block which doesn't have
the same LOCATION, or if the HAND is GRASPING some
BLOCK which is not at the same LOCATION.
More generally, we can make a list of constraints which the database
must satisfy to represent the world adequately:

.in +5
.ti -3
1. Only one thing can be grasped at a time.
.ti -3
2. A block can be grasped only if no other block is on it.
.ti -3
3. Two blocks cannot be on one block at the same time.
.ti -3
4. A block cannot move unless grasped.
.ti -3
5. A block BX can be put on BY only if BX is already at the same
location as BY and the hand is grasping it.
.ti -3
6. A block can be grasped only if it has the same location as the hand,
i.e. if both are at HERE or at THERE.
So if the hand changes its location while grasping a block, the location of
the block must change too.
.ti -3
7. (This constraint is more tricky: ignore it at first.)
A small block cannot
have anything but a small block resting directly on it. A big block can
have one big block or two small blocks resting directly on it.

.in -5
Some problems to think about:
.br
(a) How might knowledge of such constraints be represented in a program?
.br
(b) How might a robot, or a child, learn about such constraints?


Goals
.br
-----
.br
Try to work out for yourself the changes which would have to be made to
the database in order to achieve each of the following goals, starting from
the position represented in the picture above.

Assume that there is no limit to space on the TABLE at location HERE
and at location THERE.
 	(a) [GRASPING HAND B2]
 	(b) [LOCATION B4 HERE]
 	(c) [ON B3 B5]
 	(d) Nothing has location HERE
 	(e) [ON B5 B1]

For each of these "goal states" work out the sequence of changes to the
database required to bring about the goal. Make a list of the patterns
to be added to and deleted from the database, showing the order in
which the changes must occur.

Write out your answers before reading on.

.mh
Functions to represent actions
--------- -- --------- -------
.hm

Someone having to manipulate blocks in this world might find it useful to
have a collection of "action-schemas", i.e. representations of possible
actions.

How should a possible action be represented? It might be necessary to have
one representation (or program) for actually
.ul
performing
the action, and another for merely
.ul
thinking
about it, for instance while planning.

We shall consider only representations needed for planning.
Our planning system will need to be able to think about at least the following:
.in +5
.ti -3
1. Grasping a specified object:
 	FUNCTION GRASP (BLOCK);
.ti -3
2. Letting go of whatever is currently held:
 	FUNCTION UNGRASP ();
.ti -3
3. Move the hand to a specified location (HERE or THERE):
 	FUNCTION MOVETO (LOC);
.ti -3
4. Move a block to a specified location:
 	FUNCTION MOVEBLOCKTO (LOC, BLOCK);
.ti -3
5. Put a specified block on another specified block:
 	FUNCTION PUTON (BLOCK1, BLOCK2);
.ti -3
6. Put a specified block on the table :
 	FUNCTION PUTONTABLE (BLOCK);
.ti -3
7. Clear the top of a block, i.e. move everything on it to the table:
 	FUNCTION CLEARTOPOF (BLOCK);
.ti -3
8. A function to record information about actions (possibly in a list), so that
after a sequence of actions has been performed (or imagined) the program
knows what it has done.
 	FUNCTION RECORD (LIST);
.br
Assume that RECORD will be given arguments like the following patterns:
 	[UNGRASP]
 	[GRASP %BLOCK%]
 	[MOVETO %LOC%]
 	[PUTON %BLOCK1% %BLOCK2%]
.br
.in -5
How could you define functions to perform all these actions?
.br
Here are some things to think about in connection with each action:
.in +5
.ti -3
(a) What presuppositions does it make about the state of the world?
.ti -3
(b) What things does it remove from the database? (I.e. what is its
"delete list", in the terminology of the STRIPS system?)
.ti -3
(c) What things does it add to the database? (I.e. what is its
"add list"?)
.in -5

Try working out answers to these questions for some of the above functions,
then define the functions.


Sample POP11 functions
.br
------ ----- ---------
.br
Would the following be of any use?
.tp 6
 	: FUNCTION UNGRASP();
 	:	VARS B;
 	:	IF	PRESENT([GRASPING HAND ?B])
 	:	THEN	REMOVE([GRASPING HAND %B%])
 	:	CLOSE
 	: END;
.br
You could put before CLOSE
.br
 	RECORD([LET GO OF %B%])
.br
You could insert
 	ELSE 'I WAS NOT GRASPING ANYTHING' =>
.br
or some other error message.

.tp 11
 	: FUNCTION GRASP(BLOCK)
 	:	VARS L;
 	:	IF NOT(PRESENT([GRASPING HAND %BLOCK%]))
 	:	THEN	UNGRASP();
 	:		LOOKUP([LOCATION %BLOCK% ?L]);
 	:		MOVETO(L);
 	:		TRYGRASP(BLOCK);
 	:		RECORD([GRASPED %BLOCK%]);
 	:	CLOSE;
 	: END;

TRYGRASP has to see if there is anything on the block. If there is
it has to CLEARTOPOF, if not.....
.br
Complete the specification for TRYGRASP.
Try defining it. Try defining some of the other functions.
E.g. complete the following:

.tp 8
 	: FUNCTION MOVETO (LOC);
 	:	VARS L;
 	:	LOOKUP([LOCATION HAND ?L]);
 	:	IF 	L /= LOC
 	:	THEN 	REMOVE( .... );
 	:		ADD( .... );
 	:	CLOSE;
 	:END;

Test this function.

In defining the function CLEARTOPOF you may have a problem
coping with the situation where the block to be cleared as more than
one block resting on it. Use 
 	FOREACH <pattern> THEN <action> CLOSE
.br
construction for dealing with this.
For example something like this might do:
 	: FOREACH [ON ?B %BLOCK%]
 	: THEN    PUTONTABLE(B)
 	: CLOSE;
.br
where B is a local variable of CLEARTOPOF. Notice that this can
generate a recursive call of CLEARTOPOF if PUTONTABLE uses the
function GRASP.

Try defining a function called STACKUP which takes a list of blocks
and a location (HERE or THERE)
as arguments and builds a tower using the blocks in the order given in
the list, at the location specified.
E.g.:
 	: STACKUP([B1 B3 B5], "THERE");

How could you express in POP11 the equivalent of each of the
following:
 	"Put a blue block on each big block"
 	"Which big things have something blue on them?"
 	"Make a list of all the blue blocks"
 	"Stack up all the blue blocks"

A possible project would be to design a program which could
translate such English sentences into suitable POP11.
.mh
Planning actions
-------- -------
.hm
What would it be like to design a program which could itself
design functions like GRASP, CLEARTOPOF, etc? How do we do it?
We use some kind of specification of the "goal" to be
achieved. We also use the constraints listed above.
Could we express the constraints in such a form that a program
faced with the task of achieving some goal could use them to generate subgoals?
.br
For example, suppose the goal is
ultimately to ADD a pattern of the form:
 	[GRASPING HAND %BLOCK%]
.br
We could use the constraints to generate the following "subgoals":
.in +5
.ti -4
(a) REMOVE any assertion that something other than BLOCK is grasped.
This uses constraint no 1.
.ti -4
(b) If anything is on BLOCK, then put it on the table (constraint 2).
.ti -4
(c) Find the LOCATION L of BLOCK and achieve the goal
 	[LOCATION HAND %L%]
.br
(constraint 6).
