Atom and plan instances

An atom instance is defined as follows:

Definition 4.1.1(atom instance). An atom instance is a tuple (i, a, j, n) where:

• i ∈ ID is the unique id;

• a is the atom (which need not be ground); 67

• j ∈ ID is the id of the parental plan instance; and • n ∈ N is the cycle when the atom instance was created.

Given an atom instance (i, a, j, n), i is restricted to be unique among ids of other atom instances and plan instances. j is the id of the plan instance which creates this atom in- stance by means of a subgoal action. Thus, the atom instance is a subgoal of the plan instance with id j. If an atom instance is not a subgoal of any plan instance, j = nil.

Example 4.1.1. Let us return to the example presented in Section 3.5. A belief which states that room 1 is dirty can be stored by the following atom instance:

(6, belief(dirty(room1)), nil, 3)

In this atom instance, 6 is the id. The predicate belief is used in the second component to denote that this is an instance of a belief. The third component is nil which means that this atom instance is not a subgoal of any plan instance. Finally, number 3 says that this atom instance appearing since cycle number 3 in the run of the agent.

A plan instance is defined as follows.

Definition 4.1.2. (plan instance) A plan instance is a tuple (i, πinit, π, θ,fs, js, n) where:

• i ∈ ID is the unique id. • πinitis the initial plan.

• π is the plan.

• θ is a substitution for variables in the plan. • fs is the set of state flags.

• js is the set of ids of justifications.

Similar to atom instances, the id i of a plan instance p = (i, πinit, π, θ,fs, js, n) is unique

among ids of other plan instances and atom instances. Let r be the object-level rule which creates the plan instance. The initial plan πinit is a copy of the plan of r. Justifications

specified by ids in js are atom instances which were used to evaluate the reason part of r. The substitution θ is initially obtained by the evaluation of the reason and the context of r against the set of atom instances forming the agent’s mental state. The execution of this plan instance can give rise to a subgoal (which may not be ground). When this subgoal becomes a justification of another plan instance p′, variables in the subgoal is propagated to the plan instance p′and can be instantiated (such as by the test goal action). One can extend these instantiations to the substitution of the plan instance p (when p′is completely executed) by means of the meta action set-substitution. The initial plan πinit and the set js are unchanged during the lifespan of the plan instance. Together, they

are used to prevent the same object-level rule being applied twice. If the plan instance (i, πinit, π, θ,fs, js, n) is in the plan state of the agent, the object-level rule r will not be fired

again to generate another plan instance which shares the same initial plan πinitand the set

js of justification ids even if both reason and context parts of r are true. Only when the plan instance is removed from the plan state, can the rule r be applied again.

Executing a plan instance means to execute the plan π. When the plan instance is created, π is the same as πinit. When the plan instance is executed, the first action of π

will be performed and removed from π. Therefore, the plan π is sometimes called the remainder plan of the plan instance.

Example 4.1.2. The agent in Section 3.5 may have the following plan instance, which is generated by the object level rule (3.13), in order to clean room 1:

(8, !goal(pos(room1)); V acuum(), V acuum(), {X/room1}, {6}, {intended, stepped}, 5)

The initial plan of this plan instance is the same as the plan in the object level rule (3.13) with the variable X is bound to room1. This binding is stored in the substitution compo-

nent of the plan instance. The set of justification ids of this plan instance is the singleton {6}, as this plan instance has only one justification with id 6. In the set of state flags there is the flag intended, i.e., the plan instance is an intention, and the flag stepped, i.e., the plan instance has just been executed in the last cycle.

Recall that atom instances and plan instances can be related. Their relationships are stored in the parental id of an atom instance, specifying a subgoal relationship, and the set of justification ids of a plan instance, specifying a justification relationship.

Each atom instance may be a subgoal of at most one plan instance since the atom instance has at most one parental id. While a plan instance can have multiple subgoals over time, it has at most one subgoal at a time. The reason is that if the plan instance has a subgoal, the plan instance is not executable. The current subgoal must be therefore achieved before it is possible to execute the plan instance again. Note that if a plan instance is deleted from the plan state, its subgoal is also deleted from the mental state.

In contrast to subgoals, a plan instance may have several justifications. The justifica- tions are determined when the plan instance is created by applying some object-level rule. Conversely, an atom instance can be the justification of several plan instances. If the justi- fication of a plan instance is deleted from the mental state, the plan instance is also deleted from plan state. However, if a plan instance is deleted from the plan state, its justifications are not deleted.

In order to have succinct references to components of atom instances and plan in- stances, we define the following functions:

• Given α = (i, a, j, n), we define id(α) = i, atom(α) = a, par(α) = j, and cycle(α) = n. • Given p = (i, πinit, π, θ,fs, js, n), we define id(p) = i, init(p) = πinit, plan(p) = π,

subs(p) = θ, flags(p) = fs, justs(p) = js, and cycle(p) = n.

Example 4.1.3. For the atom instance α in Example 4.1.1, we have that: id(α) = 6, atom(α) = belief(dirty(room1)), par(α) = nil, and cycle(α) = 3.

Given a set of atom instances A, we denote IDAto be the set of all ids of atom instances

in A, i.e., IDA= {id(α) ∣ α ∈ A}. Similarly, given a set of plan instances Π, we denote IDΠ

to be the set of all ids of plan instances in Π, i.e., IDΠ= {id(p) ∣ p ∈ Π}.

In order to have succinct presentation of the update of components in a plan instance p= (i, πinit, π, θ,fs, js, n), we define the following auxiliary functions:

add-flag((i, πinit, π, θ,fs, js, n), f ) = (i, πinit, π, θ,fs ∪ {f }, js, n) (4.1)

del-flag((i, πinit, π, θ,fs, js, n), f ) = (i, πinit, π, θ,fs ∖ {f }, js, n) (4.2)

set-subs((i, πinit, π, θ,fs, js, n), θ′) = (i, πinit, π, θθ′,fs, js, n) (4.3)

update-rem((i, πinit, π, θ,fs, js, n), π′) = (i, πinit, π′, θ,fs, js, n) (4.4)

update-executing((i, πinit, π, θ,fs, js, n), π′) =

update-rem(add-flag(del-flag((i, πinit, π, θ,fs, js, n), scheduled), stepped), π′)

(4.5) update-failing((i, πinit, π, θ,fs, js, n), π′) =

update-rem(add-flag(del-flag((i, πinit, π, θ,fs, js, n), scheduled), failed), π′)

(4.6) Note that the above auxiliary functions are not meta actions available in meta-APL. They will be used as abbreviations within definitions of transition rules later in this chapter. add-flag is for adding a flag f in to the flag set of the plan instance p. Obviously, if f is already in the flag set, the resulting plan instance of add-flag is the same as p. Similarly, del-flag is for removing a flag f from the flag set of the plan instance p. set-subs extends the substitution of p by the substitution θ′. update-rem is for replacing the current plan with the plan π′. The last two functions update-executing and update-failing is for replacing the flag scheduled in p with the flag stepped and the flag failed, respectively. They also replace the plan of p with a new plan π′.