/*****************************************************************************/
/** P.-J. GAILLY and J.-L. BINOT, BIM -- format: plain text                 **/
/*****************************************************************************/

                               ICLP'91 Conference,

	    Workshop on merging Object Oriented and Logic Programming

                              Paris, June 24th 1991

                                  Position Paper

				 B.I.M. S.A./N.V.
				   4 Kwikstraat
			    B-3078 Everberg (Belgium)
			      Fax: + 32 2 725 47 83

	Contact: Dr. Pierre-Joseph GAILLY, Project Manager (pjg@sunbim.be)
	   or Dr. Jean-Louis BINOT Scientific Director (jlb@sunbim.be)


1. INTRODUCTION

Being a manufacturer of Prolog environments and a software house trying to
apply both logic and object oriented programming techniques to solve
complex application problems, BIM is directly interested by the topic of
this workshop.

In fact, BIM started to explore these aspects a few years ago, developing
an object oriented environment, called BIM_Probe, on top of Prolog. Along
with this aspect, mainly focusing at the conceptual modelling level, we now
investigate the issues involved in the integration of the logic programming
and object oriented programming paradigms at the language level.

Some of our main topics of interests, related to the developments done and
to the questions debated, are summarised below.


2. THE BIM-PROBE EXPERIMENT

BIM-Probe [1,2,3,4] (BIM PRolog OBject-oriented Extension) is an
object-oriented environment built on top of Prolog.  This environment is
mainly geared towards the representation of conceptual information and as
such provides good conceptual modelling and knowledge representation
facilities.

This environment supports most of the usual features of object oriented
systems (with the exception of encapsulation) but also focuses on the
problems raised by the definition of user-defined constraints and the
automatic checking of the consistency of a knowledge base according to such
constraints.  In this context, the word "constraint" is used in the sense
of "restriction" on a model definition and its possible instances, which is
quite restricted compared with the standard constraint logic programming
terminology.

The current Probe system, which is the result of approximatively 7
man-years of effort, has reached the state of a pre-product alpha release,
and is being used and tested by BIM and several other partners in the
context of two Esprit projects (TEMPORA and MMI2) and of the IRHIS AIM
project..


BIM-Probe is composed of three main components, implemented in Prolog by BIM :

 1. Probe itself, the core object-oriented system; it is a set of Prolog
    predicates implementing the basic object-oriented concepts.

 2. PCL, "Probe Constraint Language" which allows the user to easily specify
    constraints to be checked by the system, and also to query the object base
    defined within Probe;

 3. A graphical Man-Machine-Interface (MMI).

In addition, both Probe and PCL offer an API (Application Programmer Interface)
for Prolog programmes.

The core system of Probe supports the concepts of classes, metaclasses and
instances, properties and facets, procedural attachment, constraints and
methods, inheritance, and consistency checking.  Consistency checking,
especially, has received a lot of attention.  A model of consistency,
distinguishing three levels (atomic, horizontal and vertical consistency)
has been defined. A transaction mechanism has been implemented within Probe
itself to support the creation and maintenance of consistent knowledge
bases.

Also noteworthy, from an implementation point of view, is the support of
persistence of instances, which can be achieved by storing them in a secondary
storage Prolog database using the "clause DB" facility provided by Prolog By BIM.


3. OTHER ISSUES OF INTEREST

Although Probe offers interesting features from the point of view of object
oriented systems, it was implemented ON TOP OF Prolog, relying on its
underlying mechanisms. As such, Probe did not really address the larger
issue of integrating the object oriented programming and logic programming
paradigms.

Nevertheless, answering this integration question has a crucial importance
both from research and industrial points of view. The coexistence and
cooperation of the two programming paradigms should be defined in the
fairly short term. If this cannot be achieved, a convincing explanation
should be provided; otherwise the chances of any significant penetration of
logic programming in the software market will remain very slim.

As far as organisation is concerned, two exploration lines currently seem
attractive: either tackle the problem from a more theoretic point of view
and extend Prolog with concepts imported from the object oriented paradigm,
or adopt a more pragmatic view and interface Prolog with existing object
oriented packages.  The first approach can be achieved by various means
ranging from translation of object oriented constructs into Prolog by
programme transformation, extensions to the Prolog engine, to the design of
new languages integrating various paradigms.  The other approach has a
greater industrial flavour and is suggested by the existence of object
oriented tools such as C++ and Ontos; why not interface these with Prolog
according to the programmer's needs ?

Beyond such organisational questions, more fundamental issues must be
raised: What is the intended use of such integrated approaches?  What
object oriented features do we need/want if our basic programming language
is Prolog?  What are the weaknesses of Prolog that object oriented
programming addresses?

Distinguishing between the more traditional notions of "data modeling" and
"process modeling" might be useful to address such questions. The basic
philosophy of Prolog naturally tends to obscure the distinction. But
actually it can be said that Prolog does not fare equally well on both
sides.

 * Given its logical semantics, Prolog is rather good at data modeling, 
   that is at describing states of affairs for which certain relations hold.
   One may wish better structuring tools for the "conceptual modeling" part,
   such as hierarchies of classes and inheritance, but this can be imported 
   from the large body of results in the knowledge representation field, 
   and is not exclusively related to object oriented systems.

 * On the other hand, Prolog is not as good at process modeling. Processes
   inherently have states; therefore state changes and sequences of operations
   required to achieve such changes should be represented.

   In almost all interesting large scale software applications the state's
   representation is large (e.g., all accounts in a large bank, the status of a
   large computer network...). Then the only practical way to deal with changes
   is to ALTER the representation.

   In Prolog, this procedural approach does not integrate nicely with the
   declarative semantics. Extensions towards modal logics (by introducing 
   explicit sequentiality operators) and/or non monotonic logics, or truth 
   maintenance systems (to allow state changes) could conceivably deal with 
   these problems in the logic framework. But practically usable 
   implementations are not expected in the short term.

   Object oriented programming introduces the notions of object's internal 
   state and of message passing, more related to process modelling.  
   The impact of this on logic programming methodology is less clear. 
   Furthermore, as the underlying programming paradigm used to write methods 
   is supposed to provide the facilities to deal with state changes and 
   sequentiality, we are back to the previous point.

4 CONCLUSIONS

This short position statement has introduced the background work done in
object oriented tools mainly geared at conceptual modelling which was done at
BIM in the past years.  Some of the viewpoints from which we try to approach
the yet unsloved problems of integrating logic and object oriented programming
have also been outlined.

As was pointed out, this problem is not only relevant to the academic world;
given the current industrial object oriented trends, the position of the two
approaches must be made clearer, and closer: It would certainly be better to
find sound and practical means for logic programming to coexist and cooperate
with object oriented programming.

5 REFERENCES

[1] I. de Zegher, J-M Trinon and E. Meirlaen : "Reinforcing Consistency in an
Object-Oriented System by the use of a constraint language" Proceedings of the
first conference on Technology of Object-Oriented Languages and Systems (TOOLS
89), Paris, November 13-15. 1989.

[2] I. de Zegher, M. Baudinet : "BIM_Probe : An Object Oriented Language on Top
of BIM_Prolog" Proceedings on the EUREKA Project PROTOS, April 9, 1990, Zurich,
Switzerland.

[3] S. Konecni, I. de Zegher : "Object-Oriented Programming and the design of
an Open System for User Interfaces" Proceedings of the 2nd conference on
Technology of Object-Oriented Languages and Systems (TOOLS 90), Paris.

[4] I. de Zegher and Philippe Jassem.  "Coupling Hypertext to an
Object-Oriented Environment". In press, Artificial Intelligence in Medicine,
May 1990
