Here - Agents Lab - University of Nottingham

CArtAgO [13]. On the other side, it has been designed having in mind agentorientedprogramming as an evolution of Object-Oriented Programming, to beexplored as a paradigm for general-purpose computing and software development[14]. Generally speaking, it is not meant to be as flexible and effectiveas existing APLs for tackling the development of agent-based systems in thecontext of Distributed Artificial Intelligence, but it is meant to provide morerobust and effective features for the development of general software systems yetcharacterized by elements of complexity related to concurrency, distribution, decentralizationof control, reactivity, etc. In that perspective, typing – as well asother mechanisms not considered in the paper such as inheritance – is consideredan essential feature.The remainder of the paper is organized as follows: In Section 2 we explainwhat kind of errors we aim at detecting by introducing typing, as an improvementof the current error-checking support provided by existing APLs in the state ofthe art. Then, in Section 3 we describe the basic elements that characterizetyping in simpAL. Finally in Section 4 we provide concluding remarks.2 Bringing Types in Agent-Oriented Programming:DesiderataWhat kind of static error checking mechanisms does the current state-of-the-artAPLs provide? Summarizing, beside mere syntactical controls, there are APLs– e.g. Jason [1] – that do not provide any particular kind of checks, while others– such as 2APL [6], GOAL [8] and AFAPL [16] – provide some basic mechanismsfor static errors detection. For example in 2APL proper warnings are generatedwhen undefined belief update actions are referenced in the agent code. Similarcontrols are present in GOAL where a check is done about non-existing userdefinedactions referenced in agent programs. For what concerns AFAPL instead,an old version of the language provides a quite rich set of static controls [2] (e.g.for incorrectly specified activity identifiers, for mistyped imports, etc.), neverthelesssuch controls have been removed – or just not re-implemented yet – inthe current version of the language.However, the current set of basic checks available in APLs, when present,is not comprehensive. Therefore MAS developers are forced to deal at run-timewith a set of programming errors that should be detected instead statically, beforerunning the MAS program. In the following we provide some main examplesof such programming errors, using a set of simple Jason source code snippets.We intentionally choose to consider samples written in only one APL just formaking the description simple and terse. However, beside mere syntactical differencesrelated to specific language constructs, through these samples we areable to outline a set of general considerations related to programming errors thatdo not hold only for Jason, but also apply to others state of the art APLs.First we consider issues related to beliefs, using the the snippet shown inFig. 1 on the left. One of the most common belief-related errors concerns referencingnon-existing beliefs in agent code, causing: (i) plan failures – e.g. line133