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].