anjo@swivax.UUCP (Anjo Anjewierden) (04/27/89)
The possible relation between Prolog (logic programming) and object-oriented programming (OOP) depends on your point of view. Prolog is well established as a language for logic programming and Prolog is based on a firm theoretical basis. The same does not apply to OOP. I feel that there are three approaches to discuss the relation between Prolog and OOP. 1) Unification of Logic Programming and OOP. This is an area of preliminary research and aims to provide a formalism in which logic programming and object-oriented ideas may be unified. Personally, I have doubts on what it would mean to have logic variables and destructive assignment in a single context. Perhaps a compromise of some description can be found, we have to wait and see. One reference to work in this direction is: J.A. Goguen and J. Meseguer, "Unifying Functional, Object-Oriented and Relational Programming with Logical Semantics", in: Research Directions in Object-Oriented Programming, MIT Press, 1987. BTW: this book contains a comprehensive selection of papers related to OOP. A more pragmatic approach is followed by the Japanese language family (C)ESP, where some of the flavour of Prolog is present in an object-oriented language. 2) Implementing an Object-Oriented Formalism in Prolog. This approach follows the idea that "whatever object-oriented programming really is" it must be interesting. It is fairly straightforward to implement your favourite OOPS on top of Prolog, especially if Prolog has modules where each module defines a class. Modules as classes (or classes as modules) ensure encapsulation and it only requires a few additional predicates to be able to create objects and send messages to them. Although this approach is not very efficient compared to what could be achieved by more elaborate approaches it is certainly worthwhile for research and experimentation. This approach also points to a fundamental problem: the data model of Prolog (i.e. the way data is represented and accessed) is not well-suited for destructive assignment. But then it was never meant to be. (C)ESP solves this by providing additional data models, more suited to the problem. 3) Interfacing Prolog to OOP Systems. This is the hybrid approach. The idea is simple, a single language (or programming paradigm) can not be ideal for all problems. A typical case is user interface development (where large amounts of data, such as pixels, must be manipulated rapidly). Prolog (and Lisp) are not well-suited and it pays to have a dedicated system deal with the nitty-gritty of displaying images and interpreting mouse clicks. The same applies to other domains, many Prologs provide interfaces to large relational data-base systems for example. The hybrid approach becomes very interesting when the interface between Prolog and the OOPS is at the right level of abstraction, such that a Prolog programmer can easily determine how and when to escape to the OOPS. ProWINDOWS and the system on which it is based (PCE^IP) are such OOPS. These systems do not make Prolog object-oriented; they make the benefits of the object-oriented paradigm available to the programmer. We use (3) when efficiency matters and when it is more natural to think in terms of objects than in terms of logic. We use (2) in combination with (3) (mainly for storage and consistency) when efficiency is not much of problem. I do not think that the "purist" approach (write it all in Prolog, or in Lisp or whatever) is a long-term proposition. There is no single language that is best for all problems, although the declarative nature of Prolog is definitely divine inspiration for the designers of the languages of tomorrow. Anjo Anjewierden University of Amsterdam anjo@swivax.uucp PCE^IP: PCE is the intellectual property of the University of Amsterdam.