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
Prolog II+ => Delta Prolog   Extension of

  • Monteiro, L., A Logic for Distributed Processes, Ph.D. thesis (in Portuguese), Technical Report, Dep. InformAtica, FCT, Universidade Nova de Lisboa, 1983. view details
  • Monteiro, L. "A Proposal for Distributed Programming in Logic" view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Pereira, L.; Nasr, R., "Delta Prolog: a Distributed Logic Programming Language", Proceedings of Fifth Generation Computer Systems, ICOT Tokyo 1984. view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Monteiro, L., Distributed Logic: A Theory of Distributed Programming in Logic, Dep. Inform,~dca, Universidade Nova de Lisboa, Internal Report, Abril 1986. view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Cunha, J., "Concurrent Execution of a Logic Programming Language" (in Portuguese), Ph.D. thesis, Dep. Informatica, FCT, Universidad~ Nova de Lisboa, 1988. view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Pereira, L.M., Monteiro, L., Cunha, J.C., and Aparicio, J.N. "Concurrency and Communication in Delta Prolog", Conf. Proc. IEE Int. Specialist Seminar on "The Design and Application of Parallel Digital Processors", Lisbon, 1988 pp. 99-104. view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Brogi, Antonio; Gorrieri, Roberto "A Distributed, Net Oriented Semantics for Delta Prolog" in Diaz, J.; et al.: Lecture Notes in Computer Science, Vol. 351; TAPSOFT'89, Vol. 1: Advanced Seminar on Foundations of Innovative Software Development, I, and Colloquium on Trees in Algebra and Programming (CAAP'89), pages 162-177. Berlin: Springer-Verlag, 1989. view details Abstract: A truly distributed operational semantics for Concurrent Logic Languages is defined here, differently from those semantics based on interleaving models. Delta Prolog and the underlying Distributed Logic are taken as case studies. A scheme for translating a Delta Prolog system into a 1-safe Petri net is given and properties of (perpetual) processes based on the notion of causality, e.g. fairness and deadlock, are addressed.
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Cunha, J.; Ferreira, M.; Pereira, L., "Programming in Delta Prolog", Proceedings of Sixth International Conference of Logic Programming, edited by Levi, G., Martelli, M., MIT Press, 1989. view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Caxvalhosa, M., Design and Implementation of a Delta Prolog Abstract Machine (in Portuguese), MSc. thesis, Internal Report, Dep. Inform~itica, FCT, Universidad~ Nova de Lisboa, 1991. view details
          in Campbell, J. A. ed "Implementations of Prolog" Ellis Horwood 1984 view details
  • Cunha, José C. and Carvalhosa, Manuel B. "A sequential abstract machine for a distributed logic language" view details Abstract: Delta Prolog is a concurrent logic programming language founded on the theoretical model of Distributed Logic and extending the Prolog language in order to allow the specification of concurrent systems. This paper describes Delta Prolog, its operational semantics and a sequential abstract machine (DAM) for the language.
          in Proceedings of the 1992 ACM annual conference on Communications Kansas City, Missouri, United States 1992 view details
  • Skillicorn, David B. and Talia, Domenico "Models and languages for parallel computation" pp123-169 view details
          in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
  • Barbosa, Fernanda and Cunha, José C. "A coordination language for collective agent based systems: GroupLog" pp189-195 view details Extract: Extensions to GHC
    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