PLACA(ID:7797/)Agent programming language Related languages
References: in Proceedings of the workshop on agent theories, architectures, and languages on Intelligent agents Amsterdam, The Netherlands 1995 Springer-Verlag New York, NY, USA view details Extract: Introduction Introduction Yoav Shoham has proposed a new programming paradigm (AOP) based on a societal view of computation. The key idea is to build computer systems as societies of agents and the central features include (i)agents are reactive, autonomous, concurrently executing computer processes; (ii)agents are cognitive systems, programmed in terms of beliefs, goals, and so on; (iii)agents are reasoning (internally-motivated) entities, specified in terms of logic; (iv)agents communicate via speech acts. Since the presentation of AOP, agent based computing has been hailed as "the new revolution in software ''[6] because agent-based systems have advantages in dealing with openness, where components of the system arc not known in advance, can change over time, and are highly heterogeneous (in that they are implemented by different people, at different times, using different problem solving paradigms). In addition, agent based systems have natural metaphor, can deal with problems such as distribution of data, control, expertise or resources and integrate legacy system by adding an agent wrapper, etc.. However, the construction of large-scale embedded software systems demands the use of design methodologies and modeling techniques that support abstraction, inheritance, modularity, and other mechanisms for reducing complexity and preventing error. Unfortunately, so far there has been few such researches in agent-oriented methodologies. If multi-agent systems are to become widely accepted as a basis for large-scale applications, adequate agent-oriented methodologies (AOM) will be essential tgl. Perhaps foremost amongst the methodologies that have been developed for the design, specification, and programming of conventional software systems are various Object-oriented approaches. They have achieved a considerable degree of maturity, and a large community of software developers familiar with their use now exists. At the same time, the OO design and development environment is well supported by diagram editors and visualization tools. But OO methodologies are not directly applicable to agent systems--agents are usually significantly more complex than typical objects, both in their internal structures and in the behaviors they exhibit. In order to construct a complete methodology for AOP, one of the essential things is to develop a programming language because agent-oriented language and the implemented architectures of agents decide about the usefulness of AOP in the applications. In this paper, we try to center upon the language problem, by providing a computable programming language--SPLAW, for BDI agent. BDI agents are systems that are situated in a changing environment, receive continuous perceptual input, and take actions to affect their environment, all based on their internal mental state. Beliefs, desires, and intentions are the three primary attitudes and they capture the informational, motivational, and decision components of an agent, respectively ll't°l. SPLAW is a programming language based on a restricted first-order logic. The behavior of an agent is dictated by the programs written in SPLAW; the beliefs, desires, and intentions of agents are not explicitly represented as modal formulas, but written in SPLAW. The current state of an agent, which is a model of itself, its environment, and other agents, can be viewed as its current belief state; states that an agent wants to bring about based on its external or internal stimuli can be viewed as desires; and the adoption of plans to satisfy such stimuli can be viewed as intentions. We just take a simple specification language as the execution model of an agent and then ascribe the mental attitudes of beliefs, desires, and intentions from an external viewpoint. In our opinion, this method is likely to have a better chance of unifying theory and practice. in ACM SIGPLAN Notices 33(01) January 1998 view details GroupLog defines extensions to the Extended Horn Clause language (EHC) [29], that are supported at two levels: L1, defines agents as program units and L2 defines groups of agents. A GroupLog system contains concurrently executing agents able to: (1) communicate through interface predicates, and (2) join groups to coordinate their activities. In the following, we first summarize EHC (see [29]), and then describe the two mentioned levels. Extract: GroupLog and other work Related Work Recently, models have been proposed based on coordination concepts aiming at integrating a number of components together such that the collective set forms a single application that can take advantage of distributed systems. Many proposals extend a base logic language for concurrency, communication and non-determinism. The base language may be Horn Clause Logic, Temporal Logic, Linear Logic or Situation Calculus. In the first case, we have Rose, DeltaProlog, MultiProlog. In the second, MetaTem. In the third, COOL and IAM and in the last case ConGolog. Specification of concurrency has also been introduced jointly with an objectoriented model such as in DLP, CSO-Prolog, ShaDE, IAM and COOL. The motivation to use EHC as the base language for GroupLog is due to its elegant interpretation of a process interaction and its rigorously defined semantics. The dynamic entities of a program can be modeled by: Processes, as April and MultiProlog; Objects, as ShaDe, Law Governed Linda, IAM, ColaS, Electra and Emerald; Agents, as ConGolog, COOL, MetaTem, Agentspeak, 3APL and Placa; Actors, as Concurrent Aggregates and Synchronizers. The interation between dynamic entities can be modeled by: Sending messages, as ShaDe, ConGolog, Concurrent Aggregates, IAM, AgentSpeak, COOL, MetaTem, April, Placa and Electra; Shared tuples, as GammaLog, PollS, Law-Governed Linda, MultiProlog and ESP. L1 vs others models In L1, we structured the concurrency and communication with the agent notion, but this language does not aim to provide a theory to model the mental state of an agent, as in MetaTem, ConGolog, AgentSpeak, 3APL and Placa. The agent behavior is only dependent on the interface predicates and its configuration, i.e. the entities are reactive and act in accordance with the interaction and its configuration, like in the actor model. This behavior is modeled by EHC clauses, with a very similar interpretation to the rule based one in AgentSpeak and 3APL. In L,, one simple form of communication is allowed: the explicit invocation of interface predicates. The notion of agent in L, integrates the logic aspect with the object-oriented model, as in [11]. In this model it is possible to model blackboardbased systems, which is only allowed in GroupLog in L2. L2 vs others models The definition of groups in GroupLog was the result of an incremental development process which started with our early experimentation with the ISIS system. Groups allow the modeling of a cooperative entity and the dynamic evolution of a system. A group can be created or destroyed, as its members can join or leave the group at any time. The group members are hidden from the outside environment. Because a group is a meta-agent, it is possible to have a group as a member of another group, so this allows the composition of the group notion, as the context notion defined in [7]. In a group we allow two forms of communication: by invocation of interface predicates or through the shared group state. So, L2 is also an experiment towards unifying distributed-memory (remote predicate call) and shared-memory models (shared data). In some of programming languages, like MetaTem, COOL and Concurrent Aggregates, the group notion is used to restrict the communication to a certain group of agents, which may alleviate some of the inefficiencies that occur in full broadcasting. In other languages, like Electra, Emerald, Synchronizers and Colas, the group is seen as a logical unit that manipulates and restricts the invocation of the members group interface. In Syneronisers, the notion of coordination is modeled by a special object (synchroniser) that restricts the invocation of the group of objects using constraints. In most of these programming languages, as in GroupLog, the group is a dynamic entity. But in Synchronizers and Colas it is possible to dynamically change the coordination behavior, which is not possible in GroupLog. In GroupLog, as in Electra and Emerald, the members of the group perceive a consistent view of: (1) the other agents who are also part of the group and (2) the shared state. The main difference between GroupLog and these languages is the group interface predicates, that may be distinct from the group members individual interface. In languages where the communication is modeled by shared-memory, like ESP and PoliS, the communication structuring is done by allowing multi-tuple spaces. In ease of PoliS there are hierarchical tuple spaces. The L2 level of GroupLog supports the structuring of the tuples space into multiple parts, as each is naturally encapsulated within a specific group such that only its members are allowed to access the group state. This is a good approach to address both modularity, information-hiding, and scalability concerns in large-scale real applications. in Proceedings of the 2000 ACM Symposium on Applied computing SAC'2000 Villa Olmo, Como, Italy view details |