In this chapter, we presented a brief review of intelligent agents and approaches to pro- gramming them. In particular, we reviewed the BDI architecture for designing agents. The BDI architecture has had a major impact on the development of research in the field of multi-agent systems, such as technologies for specifying and reasoning about agents via BDI logics, and building agent via BDI-based agent programming languages. To this
end, we also gave a brief survey of several existing agent programming languages. We then gave a comprehensive discussion on the support provided by current agent pro- gramming languages to program different deliberation strategies. We also reviewed the notion of procedural reflection in programming languages and its application to existing agent programming languages. Finally, we reviewed the result of simulating agents using translation bisimulation which enables the comparison on the expressiveness of different agent programming languages.
The agent programming language
meta-APL
In this chapter, we introduce the agent programming language meta-APL which allows one to encode the plans of an agent and to specify its deliberation strategy in the same agent program. The basic building blocks of the syntax of meta-APL are atoms, plans, and a small number of primitive operations for querying and updating the mental state and the plan state of an agent. They are then used in the syntax of other elements of
meta-APLincluding clauses, macros, object-level rules, and meta rules.
3.1
Introduction
We begin with a brief introduction to the agent programming language meta-APL. Meta-
APLis a BDI-based agent programming language that follows the same approach as other hybrid agent programming languages (like Jason and 3APL) where logical programming and imperative programming are combined. This allows meta-APL to inherit the advan- tages of both programming paradigms; in particular, mental attitudes can be specified and reasoned in an expressive logical language and intentions can be specified and executed in an imperative fashion. Furthermore, meta-APL also features procedural reflection in
order to allow the implementation of different deliberation strategies within the same pro- gramming language. In order to enable querying and modifying runtime objects (such as mental attitudes and intentions), meta-APL comes with meta queries to inspect the internal presentations of mental attitudes (e.g., beliefs, goals and events) and intentions as well as meta actions to manipulate them. Queries and meta actions to inspect and to modify the execution state of intentions are also provided.
Like other hybrid agent programming languages, the state of a meta-APL agent con- sists of two main components: a mental state and a plan state.
The mental state consists of mental attitudes, called atom instances, which represent for example a belief about the current state of affairs, a goal that the agent wants to achieve, or an event to which the agent should react, etc. Each atom instance encapsulates an atom usually of the form type(p(t1, . . . , tn)) where type specifies the type of the atom (such as
belief, goal or event) and p is the predicate of the atom with possible arguments t1, . . . , tn.
Recall that in other hybrid agent programming languages such as Jason and 3APL, each type of mental attitudes is stored in a separate base (e.g., belief base, goal base, and event base). However, in meta-APL, atom instances are gathered in the same set. There are at least two advantages in having such a design of meta-APL’s mental state. Firstly, it allows us to minimise the set of queries and meta actions for atom instances where queries to inspect atom instances and meta actions to modify them are the same for different types of atom instances. Secondly, it allows programmers to invent their own types of mental attitudes by using other symbols to denote the type of atom instances.
The plan state consists of a set of plan instances which encapsulate the intentions of an agent. In other words, they play a role similar to intentions in other hybrid agent programming languages. Similar to plans in Jason and goal planning rules in 3APL which are used to generate intentions, plan instances in meta-APL are generated by means of object-level rules.
stances in the mental state. For example, an atom instance is created in order to achieve a goal or react to an event represented in an atom instance. Here, atom instances which are used to justify a plan instance are called the justifications of this plan instance.
An atom instance can also be a subgoal of a plan instance. When executing a subgoal action of a plan instance, an atom instance is created. This atom instance is called the subgoal of the plan instance. Informally, the existence of the subgoal is because of the existence of the plan instance. Hence, when the plan instance is deleted from the plan state, the subgoal is also removed from the mental state.
In order to succinctly specify the above possible relationships between atom instances and plan instances, we assign each atom instance and plan instance a distinct identifier. In order to specify that an atom instance is a subgoal of a plan instance, the atom instance also stores the identifier of the plan instance as a parental pointer. If the atom instance is not a subgoal, this parental pointer has a special value nil. Similarly, in order specify that a plan instance is justified by some atom instances, the plan instance stores identifiers of these atom instances in a justification set. Using identifiers for atom instances and plan instances also allows us to differentiate different atom instances and plan instances even if their atoms or intentions are syntactically the same. Identifiers are then can also be used in queries and meta actions in order to correctly and succinctly refer to the instances that one needs to inspect or modify.
Atom instances and plan instances are manipulated by means of meta actions which are organised into meta rules. Each meta rule consists of a condition describing when it can be applied and a sequence of meta actions describing updates to the mental state and the plan state and enabling procedural reflection in meta-APL.
In order to specify the interaction between object level and meta level in meta-APL, object-level rules and meta rules are separated into different rule sets. Although this de- sign decision seems to separate the object aspect and the meta aspect of meta-APL, having both aspects in the same agent programming language meta-APL can provide a good en-
gineering practice.
In particular, object-level rules and meta rules are grouped into a list of rule sets which determines the order in which they are applied. Therefore, we can easily define an arbi- trary order of applying object level rules (to generate intentions) and meta rules. This allows necessary modifications to mental attitudes and intentions to happen at several times during the deliberation. For example, one can have a set R1 of object-level rules to
generate new plan instances for achieving goals, a set R2 of meta rules to process newly
received beliefs, and another set of meta rules R3 to select certain intentions to execute.
A reasonable order for these sets are R2, R1, then, R3 which can be organised by the list
(R2, R1, R3). This means the agent first updates its mental state according to new beliefs,
such as to remove achieved goals, etc., then, generates new plan instances to achieve the remaining goals, and finally, selects one of its intentions to execute in a deliberation cycle. Furthermore, as both object and meta levels in meta-APL share the same syntax for mental attitudes (atom instances) and intentions (plan instances), this leaves no space for ambiguity when specifying mental attitudes and intentions in both levels. Finally, having a separate meta language (for programming deliberation strategies) and a number of object languages where the syntax of beliefs, goals, events and intentions are different require necessarily conversion to the syntax of equivalent objects in the meta language. As both object and meta levels are in meta-APL, such a conversion are no longer needed. This certainly simplifies the programming task as well as avoids mistakes when implementing the conversion.
An agent programmer encodes an agent in meta-APL by declaring initial atoms, ad- ditional queries, additional meta actions and a list of rule sets. The execution of the agent is organised in cycles each of which involves updating mental attitudes according to per- cepts received from the environment, applying object level rules and meta rules according to the order defined by the list of rule sets, and executing scheduled intentions. Each cy- cle is numbered incrementally where the first cycle is always numbered 0. The execution
of meta-APL agents is described in the next chapter in more detail. In the rest of this chapter, we first detail the syntax of terms as the first essential building blocks of the lan- guage. Then, we present primitive operations which are a small number of predefined queries and meta actions. These primitive operations can be categorised into two groups: one consisting of operations related to atom instances, and the other consisting of opera- tions related to plan instances. In addition to these primitive operations, one is allowed to define additional queries and additional meta actions by means of clauses and macros, respectively. Finally, we introduce the syntax of object level rules and meta rules.