Delta Prolog(ID:4200/del015)Prolog extension with AND-parallelism, don't-know nondeterminism and interprocess communication using synchronous event goals. Distributed backtracking. Related languages
References: in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details in Proceedings of the 1992 ACM annual conference on Communications Kansas City, Missouri, United States 1992 view details in [ACM] ACM Computing Surveys (CSUR) 30(2) June 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 |