We have boldly stated that DLP promises to be a suitable vehicle for implementing a variety of distributed knowledge based systems. Our argument in supporting this claim, however, merely consisted in showing that our language is sufficiently expressive for implementing the examples figuring in the literature as somehow important. One question that remains to be answered, if no objections are raised to this procedure, is how efficiently DLP can be implemented. At this stage we must postpone the research necessary for efficiently implementing DLP to the future, although we find sufficient encouragement in the work reported in  [He86], describing an extension of the Warren Abstract Machine that provides instructions for process creation and communication among processes. A different approach to supporting this claim would consist of trying to establish the usefulness of DLP for (Distributed) AI by enumerating the problems and requirements of this field of research and check whether DLP satisfies these needs. Instead of an exhaustive treatment however we will highlight one issue of crucial importance and provide some pointers to the literature. By far the most difficult problem to solve in designing a (truly) distributed system is not how to distribute the data but how to tackle the problem of distributing control. Apart from solving problems in a certain domain of expertise, the system must somehow decide how to decompose a complex task in subtasks. Also, in many cases, a final answer must be constructed from the pieces resulting from processing the subtasks. Several metaphors exist that describe different solutions to these problems, ranging from the image of a hierarchic (military-like) organisation of processes to a heterarchical (market-like) configuration where processes buy or sell the needed capabilities. Cf.  [Fo81]. 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. Our distributed logic programming language, as we have presented it, offers no 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. How to deal with shared instantiations of logical variables however is not immediately obvious. Moreover, although a bit tedious, such a broadcast facility can be programmed in DLP as it is. Sending information or clauses, on the other hand, does not cause any problem, since we have provided an assert statement, that enables to dynamically modify the functionality of an object. These considerations do not allow to take our argument with respect to the usefulness of DLP any further. We must await (sic) real life applications written in DLP before passing a final judgement.