Logical Objects(ID:7154/log026)


Conery 1988

Logical oo language, which uses first-order logic to model objects with all standard features save inheritance


Related languages
Robinson Unification Logic => Logical Objects   Based on
Logical Objects => LPL   Incorporated some features of

References:
  • Conery, J. S. "Logical Objects," Fifth International Conference and Symposium on Logic Programming, Seattle, WA, 1988. pp420-434 view details
  • Ismail H. Toroslu "LPL++: object programming language with built-in inheritance through unification" ACM SIGMIS Database 29(02) Spring 1998 pp50-61 view details Extract: Conery's Language: Logical Objects
    Conery's Language: "Logical Objects"
    In this section, the logical object-oriented model proposed by Conery in (1988) is summarized. This model defines the concept of logical objects, which is used to integrate logic programming and object-oriented programming paradigms by extending standard logic programming language with non-Horn clauses. This extension is done in order to introduce the objects with changing states in the logic programming environment. This section only summarizes the main features of the Conery's model. In the next section, we define our model, which utilizes some of these features. Therefore, a more detailed explanation of these features is given in that section. Conery (1988) proposes a logic language which incorporates some object-oriented concepts. Two types of literals can be found in this language, namely, object literals and procedural literalso Procedural literals are the same as ordinary literals of First Order Predicate Logic (FOPL). Objects in Conery's language are temporary (non-persistent) entities and they are represented by object literals. During the computation, objects are created, modified by object clauses, and destroyed at the end of the computation.
    In Conrey's proposal, there are three types of rules. The first two types are in the form of Horn clauses. Rules with one object literal in their heads define the valid objects of the classes, which is used to define temporary objects. This approach can be used to define temporary objects, like a stack as follows:
    stack(ID,[]).
    stack(ID,[X I L])~-integer(X) A stack(ID,L).
    The second type of rules is used to create new instances for that class. They also have one literal in their heads; but instead of object literals, they have procedural literals. Because objects are temporary entities, the role of this clause is only to generate an object literal in the goal clause. A new empty stack instance can be created with the following clause:
    new_stack(ID)e- ( stack(ID, []).
    The most important type of rules, the so-called object clauses, has two positive literals in their heads; and they are used to define the methods that can be applied to the instances of classes. In object clauses, the Horn clause structure of the ordinary logic programming language is changed in order to introduce objects with changing states.
    There are one object literal and one procedural literal in the head of the object clause. Also, the object literal appears in the body of the rule as well with its modified form. In this way, the resolution can transform an object from one state (on the head) to another (on the body).
    An object clause is equivalent to two Horn clauses (Conery, 1988). When one procedural and one object literal from the current goal statement are simultaneously unified with the two positive literals of an object clause, the resolvent will be equivalent to doing the same operation with two Horn clauses by using the same unifier in two SLD resolution steps. SLD resolution procedure is also extended to create an inference mechanism that selects two negative literals from the goal whenever it is required and unify them simultaneously with the head literals of one object clause. The leftmost literal of the goal statement is checked against the rule base. If there is a Horn clause whose head is unifiable with this literal, then normal SLD resolution is followed. However, if there is no Horn clause satisfying this, but this literal is unifiable with the procedural literal of one of the object clause, then one more literal (an object literal) from the goal statement is also simultaneously unified with the second literal of the object clause.
    Object literals are placed after all procedural literals in the goal statement. If the unification is satisfied, the resolution step is done similar to the ordinary resolution. These two literals in the goal are replaced by the body (after applying the unifier) of the object clause. The procedural literal in the goal is replaced by all of the procedural literals of the body of the object clause, and object literal in the goal is replaced by the object literals of the object clause (i.e., they are placed at the end of the goal statement).
    Object clauses are used to define methods. A positive object literal in the head of the object clause is the actual object on which this method is executed. A method can transform an object from its current state to another state (from the object in the head of the clause to the object in the body of the clause). A method to push new elements to a stack is defined with an object clause as:
    push(X,ID) Astack(ID,S) e-integer(X) A stack (ID,[X I S]).
    Conery (1988) states that inheritance can be achieved by explicitly programming it, i.e., by calling object creation procedures of the superclasses from the subclass's object creation procedure and therefore creating two or more literals to represent a single object. However, this approach causes some problems. Object clauses get more complicated; that is, there will be a number of object literals in the head of object clauses when the inheritance link gets longer. Due to this, the inference mechanism should search a varying number of object literals in the goal statement to unify with the head of such complicated object clause. Moreover, in the case of multiple inheritance, there will be more complications if the same attribute is inherited from more than one superclasses.