The reasoner and the inferencer don't talk much to each other

problem understander? Yes, in my view. In a recent paper (Abelson, 1975b), I attempted to develop a set of intention primitives as building blocks for plans~ Each primitive is an act package causing a state change. Each state change helps enable some later action, such that there is a chain or lattice of steps from the initial states to the goal state the actor desires. These act primitives we call "deltacts". They ~re distinguished by the state they change, and are notated by the symbol ~ preceding a state name. There are nine deltacts in my system, designed (hopefully) such that they could be applied to almost any natural world content~ (Some of these deltacts make cameo appearances in a Sehank (1975) paper in this volume, 5. embellished with his idea of planboxes, and with a new deltact added~ He and I have been. trying to work out ways to graft the deltacts into an expanded Conceptual Dependency formalism)~ For purposes of the present paper, it is not necessary to explain the entire set of deltacts, but merely to focus on a portion of the machinery needed for the robot-arm and shopping basket cases~ Consider first the abstract goal (or subgoal) that an object X be located at a certain place Y. In our abstract system, the achievement of this goal requires the deltact ~PROX, a change in the proximity relations of an object. This deltact has five arguments: the actor A, the object X, the object's starting place Z, the final place Y, and the means M~ In turn, this deltact has a set of enabling states, which may have to be achieved by other deltacts. The Abelson (1975b) paper considers the general case where the~PROX may be achieved via a "carrier system" (say, an airplane) run by agents other than the main actor. If we ignore this unnecessary complication (along with one other) here, the enabling states for ~PROX may be listed as follows, where "I" denotes an instrumental device (such as a shopping cart) used for means M~ a) PROX(A,Z)--the actor must be at the starting point; b) PROX(X,Z)--the object is at the same starting point; c) HAVE(I,A)--the actor must have instrumental device; the d) UNIT(X,I)--the object must be in a "unit relation" with the instrumental device; e) OKFOR(I,M)--the device must be in good condition for the transportation means~ These enablements are very general~ They must be satisfied no matter what the content~ Perhaps the level of generality is too high, so that some of the states such as OKFOR may have a feeling of kluge about them (as Rieger (1975b) wonders), but this is not a problem for other states such as UNIT which have rather clean properties. (There are two variants of UNIT: nested ("in", or "on"), and joined ("with"). Various nice axioms characterize objects in UNIT relation, for example, common fate from ~PROX; transitivity of nesting, etc~) Concretizing these conditions to the two applications: Robot arm moving block: The arm must be at the place where the block is; the arm must have its "hand" (satisfied by definition); the object must be put in unit relation with the hand; the hand must not be damaged (satisfied by definition. Shoppgr moving an item: The shopper must be at the place where the item is; the shopper must have (say) a cart; the item must be put in unit relation with the cart; the cart must be all right for whatever it is that carts do (roll)~ In placing these two applications in parallel under a common abstract rubric, we clearly see their similarities and differences. The robot problem is simplified because its hand is always there, undamaged~ To satisfy the remaining two states enabling the desired ~PROX, it is necessary to get the arm to where the block is (another ~PROX, or in Winograd's terms, MOVE), and to join the arm to the block (a ~UNIT in our terms, or GRASP in the original)~ The supermarket problem is one more complex because the shopper may not have a cart, or may have a damaged one~ If he doesn't have one, he must execute a ~HAVE, and if it is damaged, he might execute a ~OKFOR (fix it) or a ~HAVE of another~ Additionally, he must get to where the item is (~PROX) and nest the item in the