Provided by the author(s) and University College Dublin Library in accordance with publisher
policies. Please cite the published version when available.
Title Reflecting on Agent Programming with AgentSpeak(L)
Authors(s) Collier, Rem; Russell, Sean E.; Lillis, David
Publication date 2015-10-30
Publication information Chen, Q., Torroni, P., Villata, S., Hsu, J. and Omincini, A. (eds.). PRIMA 2015: Principles
and Practice of Multi-Agent Systems, 18th International Conference, Bertinoro, Italy, 26-30
October 2015, Proceedings
Conference details 18th International Conference, Bertinoro, Italy, 26-30 October 2015
Series Lecture Notes in Computer Science
Publisher Springer
Item record/more information http://hdl.handle.net/10197/8130
Publisher's statement The final publication is available at Springer via
http://dx.doi.org/10.1007/978-3-319-25524-8.
Publisher's version (DOI) 10.1007/978-3-319-25524-8
Downloaded 2022-08-09T18:00:04Z
The UCD community has made this article openly available. Please share how this access
benefits you. Your story matters! (@ucd_oa)
© Some rights reserved. For more information, please see the item record link above.
Reflecting on Agent Programming with
AgentSpeak(L)
Rem W. Collier, Se´an Russell, and David Lillis
School of Computer Science,
University College Dublin, Ireland
{rem.collier,sean.russell,david.lillis}@ucd.ie
Abstract. Agent-Oriented Programming (AOP) researchers have suc-
cessfully developed a range of agent programming languages that bridge
the gap between theory and practice. Unfortunately, despite the in-
community success of these languages, they have proven less compelling
to the wider software engineering community. One of the main problems
facing AOP language developers is the need to bridge the cognitive gap
that exists between the concepts underpinning mainstream languages
and those underpinning AOP. In this paper, we attempt to build such a
bridge through a conceptual mapping that we subsequently use to drive
the design of a new programming language entitled ASTRA, which has
been evaluated by a group of experienced software engineers attending
an Agent-Oriented Software Engineering Masters course.
Keywords: Agent-Oriented Programming, AgentSpeak(L), ASTRA
1 Introduction
The Agent-Oriented Programming (AOP) paradigm is nearly 25 years old. Since
its inception, a number of established AOP languages have emerged, with the
most prominent being: 2/3APL [1, 2], GOAL [3] and Jason [4]. However, while
these languages have received much critical success within the AOP community,
they have been less well received by the wider software engineering community.
A useful barometer for the view of this wider community has been the stu-
dents enrolled on an Agent-Oriented Software Engineering (AOSE) module that
is part of a Masters in Advanced Software Engineering offered at University Col-
lege Dublin since 2005. Students on this course typically have 5 or more years
of industrial software engineering experience and are senior software engineers
in their respective companies. During the course, the students are exposed to
an AgentSpeak(L)-based language, which has been one of AF-AgentSpeak [5],
Jason [4], and our most recent agent-programming language, ASTRA [6].
Each year, the students have been asked to provide informal feedback on the
AOP language(s) used and to comment on whether they would consider using
such a language in a live industry application. The common response has been
“no”, with typical criticisms being the lack of tool support and the perceived
learning curve required to master an AOP language.
2 Collier, Russell and Lillis
The lack of tool support seems strange given the existence of mind inspec-
tors [7], advanced debugging techniques [8, 9], and a range of analytical tools [10,
11]. However, after delving deeper, it became apparent to us that the criticisms
were directed more closely towards the quality of the Integrated Development
Environments (IDEs) provided and their limitations in terms of practical fea-
tures such as code completion, code navigation and formatting support. Over
the years, it has become apparent that developers become uneasy when stripped
of their traditional supports and that this engenders a feeling that the languages
are not production quality.
Conversely, the perceived learning curve is less unexpected. AOP, with its
origins in Distributed Artificial Intelligence, is underpinned by a quite different
set of concepts to mainstream software engineering, where there is a clear evolu-
tion from procedural programming languages to Object-Oriented Programming
(OOP) languages. Individuals attempting to learn about AOP are confronted
with a range of concepts - beliefs, desires and intentions; speech acts; plans -
that bear little relation to mainstream programming concepts. For many, this
can act as a significant barrier to learning how to program in an AOP language.
Perhaps the most common explanation of the relationship between AOP
and OOP is the comparison table presented in [12]. This table presents a very
high-level view of AOP and OOP that treats AOP as a specialisation of OOP.
Unfortunately, it provides little practical detail. For example, how does the state
of an object relate to the state of an agent? is there any correlation between how
behaviours are specified in OOP and how they are specified in agents? when and
how will a behaviour be executed?
Answering these questions requires a more detailed comparison of AOP and
OOP. However, when attempting to create a deeper comparison, it quickly be-
comes evident that it is not possible. The main reason for this is that AOP, unlike
OOP, does not promote or enforce a consistent conceptual model (i.e. a standard
view of state, methods, messages, etc.). Instead, different languages can, and
are, based around quite different approaches. For example, AgentSpeak(L) style
languages are essentially event-driven languages. They define context-sensitive
event handlers that map events to partial plans. Conversely, GOAL is, at its
heart, an action selection language where rules identify the context in which
each action should be executed. The consequence of this diversity is that it is
more appropriate to compare specific styles of AOP language with OOP rather
than trying to over-generalise.
In this paper, we focus on understanding the relationship between AgentS-
peak(L) and OOP with the goal of trying to reduce the perceived cognitive gap.
Our approach is to start by identifying a mapping between AgentSpeak(L) and
OOP concepts in Section 2, which we then reflect on in Section 3. The purpose
of the reflection is to try to understand how to improve the design of AgentS-
peak(L) to better support developers wishing to learn the language. Following
on from this, we introduce a new member of the AgentSpeak(L) family called
ASTRA that has been designed in response to the findings of the previous sec-
tion. Full details of ASTRA are not provided in this paper. Instead, we focus on
Reflecting on Agent Programming with AgentSpeak(L) 3
only the most pertinent features. Finally, in Section 4 we present the relevant
results of a wider survey carried out on the most recent class of the M.Sc. in
Advanced Software Engineering.
2 Relating AgentSpeak(L) to OOP
AgentSpeak(L) can be prosaically described as an event-driven language where
event handlers are fired based on both the triggering event and some context.
Events, which are either external (environment-based) or internal (goal-based),
are generated and added to an event queue. Events are then removed from this
queue and matched to a rule which is then executed. The matching process
checks both that the rule applies to the event and that the rule can be executed
based on a rule context that defines valid program states in which the rule may
be applied.
More commonly, the event handlers are known as plan rules; the program
state is modeled as a set of beliefs, that are realized as atomic predicate logic
formulae; the events are also modeled as atomic predicate formulae (with some
additional modifiers); and the execution of plan rules is achieved through creation
and manipulation of intentions. Finally, external events are generated through
changes to the agent’s state (i.e. the adoption or retraction of a belief), and
internal events are generated through the declaration of goals.
It follows then, that an AgentSpeak(L) agent consists of an event queue, a set
of beliefs (state), a set of plan rules (event handlers), and a set of intentions that
are used to represent the execution of plan rules. Given that AOP is commonly
viewed as a specialization of OOP, and that agents are a special type of object,
the following outlines how AgentSpeak(L) concepts relate to OOP concepts from
the perspective of an OOP developer:
Beliefs are equivalent to fields As indicated above, beliefs form the state of
an agent. In OOP, state is defined in terms of a set of fields that hold values
(or object references). If we consider a field, such as int value; this could
be modeled as a belief value(0). Here, the value 0 is chosen as it is the
default value for integer fields in many OOP languages. To be fully precise,
beliefs and fields are not the same. Whereas fields can be modeled using
beliefs, beliefs actually encompass more than this, including environment
information, global variables, etc.
Plan Rules are equivalent to methods A plan rule associates a plan with
a triggering event and a context. Plans define behaviours and are basically
blocks of procedural code that are executed whenever a matching event is
processed and the rules context is satisfied. In OOP languages, procedural
code is defined within methods and is executed whenever the method signa-
ture is matched to a message that has been received by the object. Accord-
ingly, the AgentSpeak(L) equivalent of a method signature is the triggering
event (specifically the identifier and the number of arguments). The con-
text has no real equivalent in OOP, however, it can be viewed as providing
4 Collier, Russell and Lillis
a form of method overloading based on state (i.e. when there are multiple
rules matching a given event, the context is used to identify which of the
rules should be executed).
Goals are equivalent to method calls Goals generate events. The are then
matched to rules, which are subsequently executed. Method calls generate
messages that are matched to methods that are executed. Typically, goals
are declared from within a plan. The result is that the plan component of
the selected rule is pushed onto the program (intention) stack and executed.
Events are equivalent to messages Within AgentSpeak(L), events play a
similar role to messages in OOP. Events are used to trigger plan rules in
the same way that, for OOP languages, messages are used to invoke meth-
ods. This can be somewhat confusing because “message” is also the term
used for communication between agents, however this is not the focus here.
In OOP, the set of messages that can be handled by an object is known as the
interface of the object. This set of messages corresponds to the signatures
of the methods that are defined in the objects implementing class(es). Given
our view of events being equivalent to OOP messages, then in AgentSpeak(L)
the interface of an agent is the set of events that it can handle.
Intentions are equivalent to threads Intentions represent the plans that the
agent has selected based upon the matching of events to plan rules. The
AgentSpeak(L) interpreter processes the intentions by executing the instruc-
tions contained within the plan. In cases where the instruction is a sub-goal,
this results in an additional plan being added to the intention which must be
executed before the next instruction in the initial plan can be executed. In
most programming languages, this activity is modelled by the program (call)
stack. Intentions are simply the AgentSpeak(L) equivalent of this. Given that
an agent can have multiple concurrent intentions whose execution is inter-
leaved, it is natural to view an intention as being the equivalent of a thread.
The above mappings are intended to relate the concepts of AgentSpeak(L) to
those present in OOP. The objective behind this is to try to reduce the cognitive
gap faced by individuals who know OOP and wish to learn an AOP language.
The benefit of doing this is that someone who is proficient in OOP can use these
mappings as a starting point for their study of the language.
3 Exploring the Implications
The mapping developed in Section 2 is not only potentially useful to developers
aiming to learn AgentSpeak(L), but it is also useful from a language developer’s
perspective as it raises questions about the set of features that may be appropri-
ate for AgentSpeak(L)-style languages. In this section, we explore some of the
consequences of adopting the above mapping.
3.1 Beliefs are like fields
Understanding the role of beliefs in AOP languages can be one of the most
challenging concepts to grasp. Certainly, at a high-level it is clear that beliefs