Step Modifiers

From ABL
Revision as of 12:56, 2 August 2006 by Dbueno (Talk | contribs)

Jump to: navigation, search

Much of the expressive power of ABL results from a rich set of step and behavior modifiers that modify step and behavior processing. Modifiers are controls which modify how behaviors will interact, and which behaviors will be chosen depending on the states in the world. Below are the various types of Step and Behavior Modifiers.


There are n step modifiers.

StepModifier ::= SuccessTest
| PriorityModifier
| Persistence
| NamedProperty
| <POST>
SuccessTest ::= <SUCCESS_TEST> <LBRACE> TestExpression <RBRACE>
Persistence ::= ( <PERSISTENT> PersistenceType )
NamedProperty ::= <PROPERTY> AblName AblExpression

Modified steps are written according to the following pattern:

with ( StepModifier [ , StepModifier ]* ) Step ;

Each set of modifiers is associated with a step.


<math>n \in \mathbf{N} = \{0, 1, 2, \cdots\}</math> denotes a natural number.
<math>i \in \mathbf{Z} = \{\cdots, -2, -1, 0, 1, 2, \cdots\}</math> denotes an integer.


When specifying a step, one can annotate it with priority. A priority is an integer <math>i</math>. All other things being equal, if the decision cycle must choose between two steps in the ABT to expand, it will choose the one with higher priority.

The priority of a behavior is 0 by default.


with (priority <math>i</math>) Step;


sequential behavior Example() {
    with (priority 10) subgoal TheSugboal();

Priority Modifier

The priority modifier annotation has similar syntax to the priority modifier. The difference is that the priority modifier number is added to the priority of the parent behavior of the step being modified.


with (priority_modifier <math>i</math>) Step;


sequential behavior Example() {
    with (priority_modifier 5) subgoal TheSugboal();
    with (priority_modifier -3) act Yawn;


A step can be marked persistent, which means that no matter whether the step succeeds or fails, it will be retried indefinitely. When a persistent step is additionally modified with when_succeeds, the step will be retried as long as it succeeds; the first time it fails, it will no longer be retried. Dually, if a persistent step is additionally modified with when_fails, the step will be retried as long as it fails; the first time it succeeds, it will no longer be retried.

When a persistent step ceases being retried, its status causes the enclosing behavior to fail or succeed, depending on the success or failure of the step.


with (persistent) Step;
with (persistent when_succeeds) Step;
with (persistent when_fails) Step;

Ignore failure

The ignore_failure annotation causes its associated step A always to succeed.


with (ignore_failure) Step ;


sequential behavior Ahh() {
    with (ignore_failure) subgoal AStep();

Interesting Identities

The following identities hold.

In a behavior,

with (ignore_failure) wait;

In a behavior,

with (ignore_failure) mental_act Block;
mental_act Block;

Effect only

An effect_only step is one which runs only at the ABL runtime's discretion; that is, it's optional. A step may be so modified meaningfully only in parallel behaviors.

Assume a parallel behavior with <math> n </math> parallel steps and one effect_only step, <math> A </math>. As it executes, <math> n </math> steps are pursued in parallel. While those steps are being pursued, ABL may choose to execute <math> A </math>. As soon as the <math> n </math> steps finish <math> A </math> is immediately terminated.

There is no guarantee that <math>A</math> will be attempted at all. If pursued, there is no guarantee that it will run to completion.


with (effect_only) Step;

Post, Post-to

Two step modifiers, post and post_to, add a WME to working memory when the step completes (with either success or failure). post adds the WME to the agent’s working memory, while post_to adds the WME to a specified named working memory. The step completion WMEs are subtypes of TimestampedWME.

As an example, consider using post to modify subgoal: with (post) subgoal CatchUp(). When the step completes, with either success or failure, a CompletedGoalWME is added to working memory. A CompletedGoalWME, the definition of which is provided by the ABL runtime, contains the name of the goal, its completion state (success or failure), the name of the agent who performed the goal, any goal arguments, and, as a subtype of TimestampedWME, a timestamp. The post modifier creates the WME, automatically fills in the fields with appropriate values, and adds it to memory.

This facility can be used to provide an agent with a selective episodic memory. The future behavior of an agent can now conditionally depend on past episodic sequences. Since the ABT no longer has state for already completed subgoals and actions, an ABL agent’s reflective access to its own ABT doesn’t provide access to past episodic sequences. In the Woggle example, a follower could use the episodic information about CatchUp to stop playing follow the leader if it has had to catch up a certain number of times within a short interval (say, 3 times in the last 30 seconds). In a team situation, completed step WMEs posted to a shared memory might be used to provide lightweight coordination within a joint behavior if the more heavyweight commitments provided by further subgoaling joint goals are not needed.


with (post) Step;

with (post_to Identifier)) Step;

Team Needed for Success, One Needed for Success

This modifier only applies to joint goals.

When the local joint goal for one team member succeeds, that team member initiates success negotiation for the joint goal. What should the rest of the team members do? On receipt of the initiator’s intention to succeed, should they immediately succeed their local joint goal, thus aborting their still executing local joint behavior, or should they wait to signal that they intend to succeed until their local joint behavior and goal succeed? This choice can be controlled by the goal modifiers team_needed_for_success and one_needed_for_success. If a joint goal has been initiated with team_needed_for_success, all team members’ local copies of the joint goal must succeed before the team can succeed. Team members that are still executing their local copy of the joint behavior keep track of who they have received intentions to succeed from, but wait to send their own intention to succeed until their local behavior succeeds. The goals for waiting team members remain in the negotiating state, blocking that particular line of expansion, until all team members have succeeded and sent an intention to succeed. If a joint goal has been initiated with one_needed_for_success, then the first team member to succeed will cause the rest of the team to succeed. Team members that are still executing their local copy of the joint behavior immediately succeed their joint goal on receipt of an intention to succeed and signal their own intention to succeed. This of course removes the subtree rooted at the joint goal, including the joint behavior, and aborts any executing steps within the subtree.

These step modifiers can only be legally used on joint subgoals. An ABL program can set the default negotiation strategy to use in the absence of an explicit modifier with the compiler pragma joint_goal_success_negotiation.


with (one_needed_for_success) joint Step ;

with (team_needed_for_success) joint Step ;

Team Effect Only

This modifier only applies to parallel, joint goals.

The team_effect_only step modifier indicates that a step should be treated as effect_only with respect to the specific local copy of the joint behavior, but should continue to execute until the parent joint goal of the behavior negotiates success across the whole team. Thus team_effect_only has a combined effect: treat the step as optional for local behavior success, but continue to execute the step (or leave it available for execution in the conflict set if it isn’t yet executing) while the parent joint goal is in the negotiating state. team_effect_only can only be meaningfully used on steps of a parallel joint behavior.


with (team_effect_only) Step;