Who needs distributed logic programming?

\label{des/per/who} Now that the reader has become familiar with the language DLP, we may well try to assess what contribution DLP offers to the programming community. It is easy to observe that a number of the examples given are equally well implementable in at least one of the other languages mentioned. For example, competing implementations of the Dining Philosophers exist in Parlog and MultiLog. See  [Ri88] and  [Ka89]. The merit of DLP with respect to the examples encountered is that DLP is sufficiently expressive to provide a natural solution to all of these. Alas, the notion of a natural solution is rather subjective. In this section we will attempt to establish what benefits DLP carries for the practice of software engineering, what use it has as a implementation vehicle for AI applications, and what it offers as a specification formalism for distributed systems. \nop{ Before that however, it may be worthwhile to spent some thought to the issues arising in combining multiple paradigms. }

Software Engineering

From a software engineering perspective, adopting the object oriented approach entails that object oriented modeling becomes the central activity in the process of design. We propose DLP as a high level specification language that supports such a methodology.

Specification

\seindex{specification} Objects in DLP may be regarded as logical theories that specify the behavior of a component in a declarative way. The encapsulation mechanism provided by DLP allows to regard the answers to a method call as statements that are true for that component. Design representation technologies are classified in  [Webster] along the axes of formality and conceptual complexity. With regard to formality distributed logic programming (as embodied in DLP) lies, in our estimate of this classification, between Prolog and knowledge representation formalisms such as KEE and ART. It is not as formal though as ordinary first order (mathematical) logic or algebraic specification formalisms. This lack of formality is primarily due to the facilities offered for parallelism and the distribution of processes. The expression of conceptual complexity is definitely enhanced by the introduction of object oriented features that allow to structure a system in semi-independent entities, and a fair estimate is that distributed logic programming is comparable in this respect to frame-based languages such as KL-ONE and the methods commonly employed in object oriented design. Both distributed logic programming and the above mentioned knowledge representation formalisms have in common that their specifications are executable. In contrast to these formalisms, I wish to stress that the proposed approach is logic-based, thus allowing for a declarative interpretation of its components, insofar as these are implemented in a pure logic programming style. See  [Pada88] for examples of specifications of computational problems in Horn clause theories. However, see also  [Ho87] for a more sceptical view.

Object oriented modeling

\seindex{object oriented modeling} In designing DLP we have chosen for a rather simple object model, and we have not provided a class construct, let alone a metaclass construct. An example of a language, similar to ours in that it also supports a kind of backtrackable method call, is the language ObjVProlog described in  [Malenfant89]. This language offers a reflexive object/class model derived from the model described in  [Cointe87]. See section \ref{dig:reflex}. However, the language does not support active objects but instead supports a kind of and-parallelism, resulting from the concurrent execution of methods for distinct objects. Its computation model allows only single-threaded objects and thus offers limited parallelism. In order to serve as a flexible vehicle for the specification and implementation of object oriented systems, the language DLP needs to be embedded in a suitable programming environment, including facilities for interactive use and documentation support. An extension of DLP incorporating hypertext features, along the lines sketched in  [PCKW89], is conceivable. As references to hypertext, consult  [Conklin87] and  [Meyro86].

Combining multiple paradigms

\seindex{combining multiple paradigms} Despite the fact that Smalltalk has (re) introduced the concept of object oriented programming, the idea of extending a given language (such as Pascal, C, Lisp or Prolog) with object oriented features seems unavoidable, regarding the numerous reports on these efforts. Less common is to extend a given language with features that enable parallel/distributed programming, but also in this respect our effort is far from unique. In the previous section, we have motivated our design choices by a comparison with other similar approaches, and we have shown that our approach is unique in so far that it supports global backtracking over the results of a rendez-vous in a distributed context. Another contribution of our language lies in its computation model, where we make a distinction between objects (embodying a state) and processes associated with an object, that carry out the activity of that object -- its own activity and the evaluation of method calls -- partly concurrently. The last issue, we wish to discuss is to what extent we should support an interface to a more efficient (imperative) language such as C++ or Eiffel. For actually implementing systems, such an interface would offer the opportunity to arrive at an efficient implementation in an evolutionary way. It is at present, however, difficult to conceive of how such an integration should take place, that is how to specify an interface between the two levels in a sufficiently abstract way. For examples of such an integration see  [BL86] and  [TC86].

Artificial Intelligence

In the area of Artificial Intelligence, Prolog has proven to be a powerful tool for implementing intelligent or knowledge-based systems. C.f.  [Bratko]. Applications of object oriented technology to AI problems are described in  [Tello89]. Currently, there is a debate as to what contributions an object oriented approach offers to AI. See  [OOPSLA91]. Apart from solving a number of software engineering issues, we regard the power of the object oriented approach to lie primarily in its imperative to attain a natural model of the problem domain. Such an approach has been successful in developing expert systems and is promising, to my mind, for the development of other complex systems as well. C.f.  [Ai80],  [HL89],  [KT90]. The contribution of DLP to AI is clearly its potential to implement distributed knowledge-based systems, whereby it inherits all the advantages of its base language Prolog. Since DLP is a general purpose language it allows to implement a variety of protocols for reaching a conclusion in distributed reasoning. An example of such a protocol is sketched below.

Contract negotiation

\disindex{contract negotiation} A very interesting solution to the effective mating of tasks and capabilities is provided in  [Da80] where the active participation of both processes needing and processes offering a certain capability is described as contract negotiation. The idea is that a process that needs some task to be performed broadcasts a message, inviting processes to subscribe to the task and state their price. After a certain time then the process that initiated the subscription decides what offer, if any, is the most suitable. Further negotiation may follow if the process does not accept the task after all, or if it needs some further information or capability to perform the task effectively. In the latter case the initiating process may send the required information or capability. \nop{ Broadcasting -- that is restricted broadcasting, limited to a designated collection of processes -- is quite easily implementable in DLP. }

Broadcasting

\disindex{broadcasting} Our language DLP does not in its turn support features that are offered by other languages. For example, DLP does not offer facilities for broadcasting messages. It may be worthwhile to consider incorporating a restricted broadcast facility, for instance to send a message to all instances of a named object. However, how to deal with shared instantiations of logical variables is not immediately obvious. A restricted broadcast facility can however be quite easily programmed in DLP as it is. Moreover, DLP allows to assert clauses dynamically, hence the required functionality may be sent to the selected processes in the form of clauses.

Distributed Systems

Distributed systems have a high degree of non-determinism, due to the assumption that each component in such a system may have its own behavior. The verification of such systems is a difficult problem. \seindex{distributed systems}

Verification

\disindex{verification} Verifying a distributed system is a difficult task. Evidently, this task is even harder when the system is specified by means of low-level concurrency and communication constructs. The introduction of an object-based approach, based on tasks and communication by rendez-vous, was motivated by the wish to make the verification of such systems more amenable. However, for languages such as Ada and POOL (embodying this approach), the number of details that must be taken into account make such a verification an almost infeasible task.

Prototyping

\seindex{prototyping} \disindex{prototyping} The language Multilog (see section MultiLog) was explicitly developed as a prototyping tool for Ada-like programs with the intention to make the verification of such programs easier. In  [Ka88a] an example of this is reported, demonstrating how the use of a high level language facilitates the reasoning about the synchronization and communication aspects of a complex system. In a similar vein we propose DLP as a language for prototyping distributed systems, to enable the specification of process creation and communication in an abstract logical way.

Partial failure

\disindex{partial failure} Also, although we have provided primitives for allocating objects and processes, we have not provided support to deal with partial failures due to hardware errors and the like. Instead, we have relied on the failure mechanism of Prolog to deal with cases of this sort. In specifying the communication mechanism, however, we have laid down the requirements that must be met for reliable communication. These requirements are formalized in the appropriate sections in part II, by providing a mathematically well-founded description of the interaction between objects and processes.

Applications

\disindex{musical composition systems} \disindex{telecommunication systems} An example of modeling an interaction protocol in a high level language is given in  [Ar86], discussing the issues that arise in telecommunication systems. Another interesting area of application is the development of musical (composition and sound synthesis) systems, that are of an intrinsically concurrent and distributed nature. In this area also, the object oriented approach has proven to be fruitful. See  [Pope91].