---
title: "Extending Logic Programming to Object Programming: The System Lap"
authors:
  - "Herman Iline"
  - "Henry Kanoui"
doi: ""
url: "https://ijcai.org/proceedings/1987/7"
pdf: "https://ijcai.org/proceedings/1987/0007.pdf"
venue: "Proceedings of the Tenth International Joint Conference on Artificial Intelligence"
year: 1987
pages: "34-38"
track: "Architectures and Languages"
keywords:
---

# Extending Logic Programming to Object Programming: The System Lap

Herman Iline, Henry Kanoui

*Proceedings of the Tenth International Joint Conference on Artificial Intelligence*, pages 34-38.

## Abstract

Object oriented programming aims at code lisibility and conciseness via abstract data type declarations and takes advantage from setting the objects (ie data) in the center of the application, Instead of procedures or demonstrations. Just as In Logic programming, where describing the properties of the solution of some problem is (theoreticaly) enough to allow the program to compute the solution, Object programming proceeds from the fact that purely declarative information leads to more procedural behaviour. It appears that Logic programming and Object programming are complementary In the sense that the first Is very sui~ble for expressing subtle reasoning, but rather weak as a formalism for describing complex structures, and conversely for the second. These considerations led us, at the IIRIAM, to combine Logic and Object programming in order to use the advantages of both. Our research effort resulted in the system LAP, an extension of Prolog to object programming, giving a new dimension _to the latter, through logic programming concepts: process1ng of partially known data and non determinism applied at the object level. The first part of this paper introduces the main characteristics of LAP, faced with the requirements of AI application development. The second part illustrates some of these capabilities through simple examples.

## Full text

## EX1"El'[)N3 LOGC Pf()GRM1MN3TOOBJECf PF03FWv1MNG :THE SYSTEM l..PP

## Herman tUNE & Henry KANOUI

tnstitut International de Robotique et d'lntelligence Artificielle de Marseille

13241 Marseille Cedex 1 France

entities, the expertise consisting In dealing with th~se interactions? In other words, Is It the power of the reasom.ng modules or the ability to describe complex universes wh1ch determines the choice of the tools and techniques?

## ABSTRACT

Object oriented programming aims at code lisibility and conciseness via abstract data type declarations and takes advantage from setting the objects (ie data) in the center of the application, Instead of procedures or demonstrations.

Just as In Logic programming, where describing the properties of the solution of some problem is (theoreticaly) enough to allow the program to compute the solution, Object programming proceeds from the fact that purely declarative information leads to more procedural behaviour.

It appears that Logic programming and Object programming are complementary In the sense that the first Is very sui~ble for expressing subtle reasoning, but rather weak as a formalism for describing complex structures, and conversely for the second.

These considerations led us, at the IIRIAM, to combine Logic and Object programming in order to use the advantages of both. Our research effort resulted in the system LAP, an extension of Prolog to object programming, giving a new dimension \_to the latter, through logic programming concepts: process1ng of partially known data and non determinism applied at the object level.

The first part of this paper introduces the main characteristics of LAP, faced with the requirements of AI application development. The second part illustrates some of these capabilities through simple examples.

## IINJBOQUCJJON

Practical applications of Artificial Intelligence, and particularly Knowledge Based Systems (or Expert Systems) Involve two key points: the representation of knowledge and reasoning modules; these will link together facts and expert rules to construct the solution of the problem in a dynamic process.

- In fact, faced with a concrete problem, at least two preliminary questions arise:
- what Is the nature of the domain to be examined, what are the entitles which compose this domain, what type of relations link these entities? Answering this first series of questions will help us to decide which knowledge representation schema to adopt.
- what kind of reasoning is to be performed on these entities? This will help to choose amongst inference engines and deduction methods.

Moreover, considering these questions will allow us to determine where the expertise is located: do we have to perform very subtle reasoning on flat and independant facts or, on the contrary, are we in the presence of deeply interconnected In the second case, it Is likely that object oriented programming will be a valuable tool to hel~ \_in solving \_the problem. We can distinguish three levels of amb1t10n of an object oriented programming language designer: .

- hierarchical modeling exploiting the inheritance mechamsm.
- communication between 'intelligenf entities.
- the construction of an abstract universe including specialized knowledge bases in order to reason on concrete objects.

The first approach (almost purely technical), aims at code lisibility and conciseness via abstract data type declaratio~s. The second one (more 'animated') takes advantage from setting the objects (ie data) in the center of the application, instead of procedures or demonstrations. T~e third approach (referr~ to as cognitive) considers abstract objects as nodes where p1eces of knowledge are centralized.

One could argue that the intelligence transmitted by this last approach proceeds from the fact that purely declarative information leads to more procedural behaviour, just as in logic programming where describing the properties of the solution of some problem is (theoreticaly) enough to allow the program to compute the solution.

The execution of a program written In an object oriented language can be seen as a communication process between objects coming up from a hierarchical univ.erse of ~stract fr9:mes. During the life of an object , its dynamiC Image IS kept cons1stent with the Image of every frame with which the object Is concerned.

Now, from a user's point of view, object oriented programming can be a valuable tool for:

- (a) Structuring (modeling) a domain;
- (b) Maintaining the consistency of the universe of frames; .
- (c) Making some superfiCial deductions on this universe, us1ng the inheritance mechanism;
- (d) Reasoning on this universe by activating more general inference mechanisms.

Depending on the respective Importance of these aspects, one can distinguish applications such as:

- (1) Structuring an abstract universe:, which Invokes aspects (a,b) above; we are only Interested In describing ~e universe.
- (2) Management of a domain of concrete object~; we are interested in exploiting the description of the umverse by invoking aspects {a,b,c). . ...
- (3) Expert systems which need, above all, reasomng capabilities taken from aspect (d).

Applications of type {1,2) are most commonly achieved by object oriented programming. For applications of type (3) this approach eliminates from the knowledge bases all 'superficial' rules based on inheritance or directly derived from descriptive information attached to the objects. There only remain truly expert rules for which inference engines are still to be developed. To achieve this, object oriented environments based on algorithmic (C, Pascal) or even symbolic (Usp) languages need a great deal of programming effort and are not well adapted to this purpose. Concerning the inference engines, those based on the production rules schema are very limited : the lack of semantics and the approximative modeling of reasoning are paid for an inflation of the number of rules and yet obtaining an uncertain (sometimes doubtful) result.

On the contrary, since we aim to formalize reasoning, we must have recourse to the mathematical logic and theorem proving which led to the so-called 'logic programming' of which Prolog is the only effective implementation. This provides us with a powerful formalism based on the notion of relation, a very precise semantics, and deduction strategies allowing the manipulation, in a non deterministic way, of very general data structures (trees with variables).

However, if Prolog is very suitable for expressing subtle reasoning, it is rather weak as a formalism to describe complex structures. This led us, at the IIRIAM, to combine logic and object programming in order to use the advantages of both. Our research effort resulted in the system LAP.

LAP is an extension of Prolog to object programming, giving a new dimension to the latter, through logic programming concepts: processing of partially known data and non determinism applied af the abstract object level:

- Objects and their slots are processed as true Prolog variables: definition of constraints on the values of object slots, processing of partially known objects. The non determinism of Prolog offers an elegant and effiCient means for such an approach which allows a high degree of versatility compared with imperative implementation languages .
- The query language of the objects data base is Horn-clause logic and is expressed in terms of relations to be satisfied (as in Prolog, ie without distinction between input and output arguments).
- The deduction capabilities provided at the object level (facets and methods) are increased by the power of Prolog as an inference engine by itself, as well as a programming language.
- Thus, LAP reassembles concepts usually dispersed between: - relational data bases (relations between frames),
- object oriented languages (parentship, inheritance, message passing),
- inference engines (slot value deductions, facets and methods),
- -logic programming (non determinism, variables) .

In the second part of this paper, we will expand upon the main characteristics of LAP and show how they fit the considerations given above. This presentation is illustrated by examples given in Quintus-Prolog syntax.

## II THE MAIN CONCEPTS OF LAP

LAP provides two distinct environments: the first one is for conceiving a universe of abstract frames, which we call models. In the context of this universe, the second environment controls the construction, evolution and reasoning of a realization, which is a set of concrete objects (or Instances) compatible with the universe's constraints. In the center of these two environments is the notion of a model and object image.

To achieve this, LAP provides a set of library predicates for creating, modifying and maintaining the consistency of a universe of objects in which:

- a concrete object is described by abstract models and inherits their generic properties.
- An abstract model is part of a hierarchy ordered by the parentship link.
- Consistency constraints, default reasoning, specific processing (methods) can be attached to a model and inherited by its instances.
- An expert system application can be seen as a sequence of goals, formulated through a dialogue, and their demonstration.

The image of a model results from:

- its position in the graph of models which supports inheritance.
- Its relationships with other models which is another means of structuring the abstract universe.
- The declarative attachments: slots, their constraints and properties.
- The procedural attachments: expert rules, facets, methods.

The image of an instance is restricted to the relations with other objects, and values assigned to slots or deduced by expert rules or inherited from the models prototyping the instance.

In LAP, the models, the slots and their properties, the facets, methods and relations are explicitly declared. Each declaration results in Prolog assertions. Facets and methods must be edited as Prolog clauses.

## A. Structural Concepts: the Graph of Models and the Relations

A model is an abstract data structure corresponding to a class of objects in the modelized universe and defined by a set of common properties. A given model may have one or several father models (direct ancestors) . Thus LAP allows multiple parentship at the model level.

A parentship link between two.models can be understood in two different ways:

- Either this link indicates that the father-model is a super-class of the son-model. For example, the model 'motor-car vehicle' is a son of the model 'land vehicule'.
- Or the father-model corresponds to a particuliar point of view of the son-model. For example, a 'motor-car' can be considered under two different points of view as 'transportation means' and 'assembly of metal parts'.

There is no fundamental difference between the two interpretations 'super-class' and 'point of view' : in the two cases the son-model inherits all the characteristics attached to the father-model. However, the second interpretation will be preferred in those cases where we do not intend to create concrete instances of the model considered as 'point of view'.

The universe is given a graph structure whose nodes are the abstract models (to which knowledge. is attached) and the vertices, denoting the parentship links, are the only vehicles of inheritance.

In addition to parentshlp, two models can be linked In LAP by one or more binary relations (as classic relations In relational data bases).These relations are another way to structure the universe and give access to the linked objects.

Let us now consider the example of a universe including human beings, wild animals, and domestic ones. Here Is a posable modellzatlon of this universe with some ·natural' relations.

![Image](https://ijcai.org/proceedings/1987/fulltext/7/image_000000_632edb1f992039cf613722fa8162ac07d20e098a4adbe572b4d5ed8403ecea5e.png)

The model and relation names are Proiog atoms. The models 'human' and ·animal' are linked by the relation 'has\_favorite\_anlmal', the symmetric relation being 'has\_master'. Equally the models 'man' and 'woman' are linked by the relations 'has wife' and 'has husband'.

The model 'canary' has two father-models:

- 'bird' interpreted as a super-class: every canary is a bird.

- 'domestic\_animal' will rather be interpreted as a point of view

on 'canary'.

In this example we do not intend to manipulate instances of 'domestlc\_animal', but the associated point of view will be useful dealing with an instance of 'canary' or 'dog'.

A similar remark can be made for the points of view 'male' and 'female' for the models 'man' and 'woman'.

The data base can be constructed step by step by invoking LAP primitives. For example,

```
1 ?- def_model(canary,[bird,domestic_animal)).
```

defines 'canary' as a descendant of the ordered set of models 'bird' and 'domestic animal'. Note that the order between ancestors is used in solving conflicts arising from multiple inheritance.

The parentship links can now be Interrogated by the primitive 'fat\_son' which links a model to its direct descendants. For example:

```
I ?- fat_son(X,canary) . X· bird ; X-domestic_animal ; no
```

Now, if the model'human\_being' is assumed, In order to define the binary relation 'has\_master' between 'human\_belng' and 'animar, we have to type: ·

```
I ?- def_link(animal,[haa_master,(0,1)}, [has_favorite_animai,[O,S)},human_being). yea
```

which Indicates that an animal has at most one master and introduces the symmetric relation 'has\_favorite': a human being has at most five favorite animals.

Here, we just Indicate the possibility that a relation can hold between humans and animals. The link will be effective at the instance level (In the concrete world) only.

The primitive 'link' gives the relations which can link two models. For example:

```
I ?- link(animai,X,human_being). X-[animal,[has_master ,(0, 1 )},human_being)
```

The term substituted for the variable X indicates the origin (through inheritance) of the ·link. If several links exist between 'animar and 'human\_being', tt)ey will all be printed.

To know which models are directly linked (without passing through inheritance) by the relation 'has\_master', one could ask:

```
I ?- faLaon(domeatic_animai,Y). Y-canary ; no I ?- faLaon(X,Y). Xaanimal, Y-ctomeatic_animal ; Xabird, Y-canary ; X-domeatic_animal, Y-canary ;
```

```
no
```

It must be noticed that when invoking LAP primitives, as is usual in Prolog, there Is no distinction between Input and output arguments. All the substitutions for the free variables which satisfy the relation are enumerated by backtracking. This feature is not usual in other object oriented languages; it is directly inherited from the underlying Prolog system.

One can also use the primitive 'anc\_off which is a generalization of 'fat\_son' and links a model to ali Its descendants, direct or not:

I ?- anc\_off(X,canary).

```
X·bird ; X-living_creature ; x-modele_type ; X-domestic_animal ; x-animal ; no
```

The order in which the results are given corresponds to a depth-first search strategy as in Prolog. This order is important: recall that the multiple inheritance schema can lead to a conflict when some Information Is searched for among the ancestors of a model. This conflict Is solved by enumerating the ancestors by a depth-first strategy and retaining the first which provides the data searched for.

```
I ?- llnk(X,(X,(has_master,A), Y),Y). x.anlmal, A·(0,1), Y·human_being ; no
```

The existence of a relation between two models Is transmitted to their respective descendants. So, to ask: "Which are the relations which link the model X, descendant of A, to the model Y, descendant of B?", one could use:

```
1 ?- link(X,(A,R,B),Y). X-animai,A·animai,R·(has_master,(O, 1 JJ, B·human_being,Y.human_being ; X- domestic_animai,A.animai,R·(has_master,(0,1 JJ, B·human_being, Y ·human_being ; X-canary ,A·animai,R·(has_master,(0,1 JJ, B-human_being, Y -human_being ; X·dog,A.animai,R·(has_master,(O, 1 IJ, B-human_being, Y ·human_ being ; X-wild_animai,A-animai,R·(has_master,(0,1 IJ, B·human_being,Y-human_being ; X-animai,A·animai,R·(has_master,(O, 1 JJ, B-human_being,Y.man; X-wild_animai,A-animai,R·(has_master,(O, 1IJ, B·human_being,Y.man; X·wild_animai,A.animai,R·(has_master,(O, 1 JJ, B·human_being,Y.woman; no
```

that is the complete set of combinations between 'anlmar and Its descendants on one hand, and 'human\_being' and Its descendants on the other hand, which Is In complete accordance with the philosophy of Prolog.

## B. Qescdptlye Concepts: Slots and !heir Values

The parentshlp links and the binary relations as shown In the graph of figure 1 reflect only the structure of the modellzed domain. To each model, node of the graph, knowledge is attached by means of declarative and procedural characteristics which will express both the Internal structure of the model itself, and its behaviour and relations with Its environment. These characteristics will later be Interpreted at the realization level by the Instances of the model.

The most elementary way of expressing the descriptive knowledge associated with a model consists in providing It with a collection of slots. A slot defined for a model Is also Implicitly defined for all the descendants of the model, via the Inheritance mechanism.

In LAP, a slot behaves like a Prolog variable and the values It can take are 'bound' terms (trees) In the Prolog sense. The set of possible values of a slot can be governed by a set of constraints and obey certain properties as decided by the programmer.

The constraints associated with a slot at the model level make It possible to specify:

- The type of the slot: Integer, real, string, list, ... and more generally any reference to type testing available In the underlying Prolog system.
- The set of legal values : the one that the slot can take at the instance level.
- ·The slot cardinality. In LAP, slots are In general multi-valued. The cardinality Indicates the maximum number of values that the slot can take simultaneously for a given Instance. As usual In Prolog, the set of solutions will be enumerated by backtracking.

## · The possibility of Inferring slot values via a binary relation.

Apart from the constraints, one can define, at the model level, properties concerning the slot values. As for constraints, these properties will be effective at the Instance level only. One can:

- Allow the prompting of a slot value, if It has not been possible to Infer It by other means.
- Specify default values for a slot. These default values will be taken Into account at the Instance level only if all other attempts to compute the slot values failed to reach the slot cardinality.

The properties and constraints above were attached at the model level. Some additional properties can be attached directly at the Instance level; they make It possible:

- To forbid certain values for a slot.
- To fix a slot value (forbid further modification).
- To declare unknown a slot value which forbids asking the user for it.

Given a model already defined, we can provide It with a new slot with the primitive 'add\_slot'. For example, we can define slots 'name' and 'home' for model'human\_belng' above by typing:

```
1 ?- add_slot(name,human_being). yes 1 ?- add_slot(home,human_being). yes
```

These slots can then be forced to obey certain constraints:

```
I ?- set_slot_property (type,(human_being,name,string)). yes I ?- set_slot_property (cardinal,(human_being,home,2)). yes I ?- set_slot_property (type,(human_being,home,string)). yes
```

which Indicates that the values of 'name' and 'home' are strings; the name Is single-valued (default cardlnality·1) but not the home (two possible addresses).

These slots can be prompted, which allows the system to question the user on their values. This Is achieved by:

```
I ?- set_slot_property (prompt,(human_being,name),default_prompt). yes I ?- set_slot_property (prompt,(human_being,home),ask_address). yes
```

which Indicates that name and home address can be computed by deleting (In the Prolog sense) the literals 'default\_prompt' and 'ask\_address' respectively.

'default\_prompt' and 'ask\_address' refer to Prolog clauses. 'default\_prompt' Is provided by LAP as a library predicate, while 'ask\_address' Is a user-defined predicate.

Now, the properties of a model slots can be interrogated by:

```
I ?- get_slot_property(X,[human_being,A,V)). X=cardinal, A=name, V=1 ; X=type, A=name, V=string ; X=prompt, A=name, V=default_prompt ; X=cardinal, A=home, V=2 ; X=type, A=home, V=string ; X=prompt, A=home, V=ask_address ; no
```

## C. Procec!ural Concepts· Facets and Methods

Having specified the links and relations of a model and also described its descriptive features, we are pow interested in expoiting this structure. In fact, apart from the usual inheritance mechanism, the use of slots and their values is governed by ad-hoc rules which constitute knowledge bases associated with the models. In LAP, there are three kinds of such rules:

- rules associated to events,
- rules for inferring slot values or relations,
- -methods.

The first two kinds of rules are implemented as facets. The last is the software support for message-passing and is nothing other than a generalization of the first two.

The generic events addressed by the first kind of rules are: - creation or suppression of a model instance: facets if\_created and lf\_suppressed.

- assignment or suppression of a value to an instance slot : facets If added and If removed.

The second kind of rules, the deduction rules, correspond to the facet lf\_needed.

At each attempt to provoke one of the events above, the corresponding facet - provided it has been defined for the model on which the considered instance depends - is fired. The event under consideration will effectively occur only if the Prolog goal corresponding to the facet can be satisfied.

The role of the rules associated to the events is to preserve the integrity and consistency of the object data base when it is modified or updated.

The facet lf\_needed makes it possible to express how the values of an instance slot can be inferred from other information. The inferred values will then simulate the event lf\_added. So, a value deduced by the activation of rules, but not consistent with the aspect if\_ added will be rejected.

Facets and methods are written in Prolog and it is important to recall that the conceptor of an application disposes of the full Pro log power to express a facet or a method. For example, the facet If needed defined for a given slot of an instance can not only invoke the value of other slots of the considered instance, but also refer to other objects (via LAP primitives), which makes it possible to chain rule activation.

## Ill REALJZAIJQ\J:JHEc:;Q\JCBEIE LJ:JIYERSE

The concrete universe is a collection of instances. The image of an instance is essentially constituted by the set of known slot values.

The life of an instance is nothing other than a succession of events including:

- the creation or the destruction of the instance,
- the setting of binary relations with other instances,
- the modification of slot values,
- the interrogation of slot values (by reading assigned values, rule inferences, deductions through relations, user inputs, or by returning default values). .

Taking these events into account is controlled by knowledge rules (ie facets, methods, ... ) embedded in the respective model images.

- LAP offers primitives to read or write, for the benefit of a given instance, the values of the slots known by the (pos~ibly multiple) models on which the instance depends. As explamed above, assigning and getting a value can be governed by programmer-defined procedures: the facets.

To illustrate these points, we will again consider the example given in figure 1. We will describe a scenario where an instance of the model domestic\_animal is created.

- (1) If, when creating a domestic animal, the name of its master is not specified, then the animal will send a message to every instance depending of an offspring of the model 'human\_ being'.
- (2) The content of this message is : "do you want me as your favorite animal?"
- (3) The addressees of the me~sage will look at some s.lots (colo~, beauty, ... ) of the animal and w1ll answer YES to the ammal only 1f the corresponding values agree with their taste.
- (4) To the human being which is ready to take care of it, the animal will send a second message whose content is: "where will you accomodate me?" ·
- (5) The animal will accept as master the first human being who answers "inside the house" .

Assuming that methods corresponding to the messages have been defined for the model 'human\_being', the implementation of this scenario requires:

- the facet if created for the model 'domestic\_animal',
- the facet i[needed for the relation 'has\_master' in the model 'domestic animal',
- and the Prolog clauses corresponding to these facets.

```
The facet declarations are achieved by: 1 ?- def_facet([if_created,domestic_animal] , create_domestic_animal). yes 1 ?- def_facet([if_needed,domestic_animal, has_master],find_master) . yes
```

The Prolog clauses 'create\_domestic\_animal' and 'find\_maste'r could be written respectively as:

```
create_domestic_animal([domestic_animai ,A) ,H, [A,K,get_slot(A,beauty, b)]) :- element([has_master, M] ,H) , !, union(H,[beauty, b), K) . create domestic animal([domestic_animai ,A), H,[A,K, gel::_and_set_slot(A,has_master,M))). fi nd_master([ domestic_ani mai ,A) ,has_master ,M) :­ anc_off(human_being, H) , population(H,P) , element(M,P) , send([A, M] , do_you_want_me,_,yes) , send([A,M),where_would_you_accomodate_me, [inside,outside],inside), ! .
```

This simple example shows how:

- the effective creation of an instance can be forbidden if certain conditions (formulated in the Prolog rules defining the facet if-created) are not satisfied.
- As soon as an instance is created, some slots or relations can be assigned a value.
- The chaining of rules is achieved by invoking, from facets and methods, LAP primitives such as interrogating the objects data base and sending/l:d<nowledging messages.

## IV IMPLEMENTATION

- LAP is implemented as a library of about 150 predicates described in detail in the LAP Reference Manual. It is available under Prolog II and Quintus-Prolog and runs under VaxNms, and Sun/Unix. Versions for Macintosh and Buii-SPS9 are under development
- LAP gives full access to the underlying Prolog system and provides a windowing and menu interface which facilitate both knowleqge acquisition and execution.
- LAP has been used in the development of several CAD systems in architecture, industrial simulation and medical consultation expert systems.
- Bobrow, D.G., and Stefik, M. "Object-Oriented Programming :Themes and Variations·, AI Magazine 6. no. 4, 1986
- 2 Giannesini, F., Kanoui, H., Pasero, R., Van Caneghem, M. "PROLOG", Addjson Wesley, 1986
- 3 lline, H. ·un Environnement Oriente-Objets en Prolog : le Systeme LAP", Proc;eedjnas of Second CHAM, Marseilles, France, 1986
- 4 lline, H. "LAP: Manuel de reference·, Internal paper. llBJAM. 1986.
- 5 Shapiro, F., and Takeuchi, A. "Object-Oriented Programming in Concurrent PROLOG", New Generation Computing,1983.
- 6 Stabler, P. "Object-Orient&ct Programming in PROLOG", AI Expert, 1986

## References

1. Bobrow, D.G., and Stefik, M. "Object-Oriented Programming :Themes and Variations•, AI Magazine 6. no. 4, 1986
2. Giannesini, F., Kanoui, H., Pasero, R., Van Caneghem, M. "PROLOG", Addjson Wesley, 1986
3. lline, H. •un Environnement Oriente-Objets en Prolog : le Systeme LAP", Proc;eedjnas of Second CHAM, Marseilles, France, 1986
4. lline, H. "LAP: Manuel de reference•, Internal paper. llBJAM. 1986.
5. Shapiro, F., and Takeuchi, A. "Object-Oriented Programming in Concurrent PROLOG", New Generation Computing,1983.
6. Stabler, P. "Object-Orient&ct Programming in PROLOG", AI Expert, 1986 lline and Kanoui