Prolog++ toolkit - Details

How OOPS benefits from Logic

• Prolog is a type free language (i.e. variables are not constrained to certain data-types). This allows greater freedom for the programmer than a typed language, leading to an increase in both productivity and creativity.
• All data structures in Prolog are dynamic. The creation and garbage collection of data structures is automatic. A Prolog-based OOPS will reflect this by allowing truly dynamic class hierarchies.
• In addition to these, Prolog++ may be fully integrated with standard Prolog programs. Each Prolog++ class has access to all Prolog predicates, whether system-defined or user-defined. This allows Prolog++ to inherit all the capabilities of a fully developed Prolog environment like list processing, unification, backtracking.

Adding OOPS to Prolog

• Prolog imposes very few restrictions on the structure and organisation of a program. This is fine for small scale programs, but can lead to problems when constructing large applications. The onus is on the programmer to impose some discipline for organising and managing their code. The ability to define a class hierarchy allows the programmer to partition Prolog programs into dynamic modules which helps organise a program and closely resemble the structure of the problem domain.
• Each class within Prolog++ also has a clearly defined interface formed by the names of its methods which corresponds to its abstract or outline. The ability to define classes whose interface corresponds to their function is also of use when trying to model the problem domain.
• The ability to have a close resemblance between a class, its interface and the problem domain enables the interfaces to the classes to be easily understood. This coupled with the encapsulation of the classes into packages of code and data allows Prolog++ programs to be re-used like building blocks.
• Data-Driven programming is supported by allowing daemons to be attached to crucial events. The mechanism for trapping events is incorporated in the Prolog++ engine itself and does not need to be explicitly handled by the user.

Prolog as a logic-based language

The way Prolog does this is by using a built-in inference engine, which automatically infers the solution to a given query using the facts and rules as defined in the program. Prolog programs consist of facts and rules, which are referred to as clauses. A fact consists of a single assertion with no conditions: a fact is always true. A rule consists of a goal, whose truth is dependent upon a set of conditions or sub-goals. The goal of a rule is referred to as its head and the sub-goals as its body.

Prolog attempts to prove a goal by using its backward chaining inference engine to match the initial goal with either a known fact or the head of a rule. If the goal is matched with a known fact the goal is proven. If the goal is matched with the head of a rule the original goal is then replaced with the sub-goals which form the body of the rule. Prolog then attempts to prove, in the same way, each of these sub-goals in turn.

Although Prolog programs are thought of as declarative they can also have a procedural reading. Prolog is versatile: there is a style of Prolog programming which mimics the conventional procedural approach, but with less emphasis on the actual assignment statements.

Prolog as a logic programming language has a sound theoretical basis, being modelled on the first-order predicate calculus. This means that theoretically a Prolog program, which may be read as a set of axioms and theorems, contains the possibility of being proven consistent or inconsistent, regardless of the implementation. In this way Prolog can be thought of as an automated theorem prover.

Variable Types

Data Structures

Memory is dynamically allocated and deallocated at run-time. The deallocation is automatically done by a built-in garbage collector. The programmer does not have to be concerned with the implementation, maintenance and bookkeeping normally associated with the creation and destruction of complex dynamic data structures and is freed to concentrate on stating the logic of the problem.

Prolog is now in widespread use in industry and the ISO Prolog standard was published in 1995. The Prolog Management Group was formed in 1993 to promote and highlight the various commercial applications fo Prolog.

Interfacing to external code and data

Development facilities

• object-browser to interactively browse classes and instances
• methods editor to interactively edit and compile methods
• object-graph to graphically display and interact with the classes

History and availability

1994, Addison-Wesley published "Prolog++: The Power of Object-Oriented and Logic Programming" by Chris Moss. In 1995, LPA released v2.0 which introduced part-of hierarchies to supplement is-a hierarchies and other extensions.

Notation

Method/Arity
Methods are referred to by the / symbol, with the name of the method on the left and its arity (number of arguments) on the right.
Function//Arity
Functions are referred to by the // symbol, with the name of the function on the left and its arity (number of arguments) on the right.
Attribute
Attributes are referred to by their name alone.
Instance <- Message
<- is the principal symbol of Prolog++, and indicates that the message on the right is to be sent to the instance on the left.
Instance@Attribute
@ is the symbol used to indicate the value of an instance's attribute.

Program Statements

1. code statements which define how various kinds of messages are handled
2. meta statements which talk about the class and its methods

Logical variables

Instance variables

1. self substituted at run-time by the instance, or class, to which the message being handled was originally sent
2. super substituted at compile-time by the super class of the class in which it textually occurs

Is-a hierarchy

class stack.
   inherits buffer             % inherits all characteristics of buffers
   ...
end stack.

class queue_with_statistics.
   inherits queue,             % inherits from general queues
   buffer_with_statistics      % as well as statistical buffer
   ...
end queue_with_statistics.

The is-a hierarchy can be navigated by referring to super, sub, ancestral and descendant classes. This is expressed by a collection of reserved words:

• super_class - the/a super or parent class
• sub_class - a sub or child class
• ancestor_class - a super class (parent), or a super-super class etc.
• descendant_class - a sub class (child), or a sub-sub class (grandchild), etc.

Part-of hierarchy

class bicycle.
   parts frame, wheel * 2, seat, handle_bars.
end   bicycle.

class unicycle.
   inherit bicycle.
   parts wheel, handle_bars * 0.
end   unicycle.

class tandem.
   inherit bicycle.
   parts seat * 2, handle_bars * 2.
end   tandem.

Composite instances

.

class cycle_component.
public method when_created/0.
when_created :-
   write( 'Created: ' ),
   write( self ),
   nl.
end cycle_component.

Accessing Part-of hierarchy

• composite_part - the top-most instance in this part-of hierarchy
• super_part - the super or parent instance which this is a part of
• sub_part - a sub or child part of this instance
• # - a specifically numbered sub part.

Attributes

A public attribute is one whose value is accessible from outside the class in which it occurs, whereas a private attribute can only be accessed from within. In either case, the attribute's value can only be changed from within the class.

public class attribute
   smallest .                 % the smallest instance in
            .                 % this class; no default value

private instance attributes
   contents = [] , .          % default contents is empty list
   size is 0 , .              % the default size is zero
   cumulative_size inherited .% cumulative size is inherited
            .                 % from an ancestor class

Assignment

1. "Name of Attribute" := "New Value"
2. "Name of Attribute" :== "New Value"

A Case Study In Fault Diagnosis

The Problem

The crucial factor in fault diagnosis is being able to quickly pinpoint the general area of the problem, before focusing in on the root cause. Identifying general aspects of the problem can avoid going down blind alleys, and more importantly avoids asking the user seemingly irrelevant questions.

For the domain of car maintenance, an automobile can be dissected into several problem areas such as the fuel system, mechanical faults and electrical faults. Associated with each area is a collection of faults which may occur, and the symptoms which they cause. Some of the symptoms may be contradictory, in the sense that two symptoms cannot possibly occur simultaneously.

The Classes

The following example illustrates a hierarchy for identifying faults in automobiles. At the topmost level is the faults class containing the algorithm for finding faults, and which is inherited by all of the other classes in the hierarchy. At any point, however, a class has the option to override the default search algorithm with one that is specialised for its problem area.

The following sections define the protocol (attributes, methods and functions) for the faults instance and for the domain specific objects.

The Domain Classes
class   mechanical.
inherit fault.
end     mechanical.

class   engine.
inherit mechanical.
end     engine.

class   cylinders.
inherit engine.
end     cylinders.

class   fuel_system.
inherit fault.
end     fuel_system.
class   electrical.
inherit fault.
end     electrical.

class   lights.
inherit electrical.
end     lights.

class   starting.
inherit electrical.
end     starting.

class   starter_motor.
inherit starting.
end     starter_motor.

class   sparking.
inherit starting.
end     sparking.

class   plugs.
inherit sparking.
end     plugs.

class distributor.
inherit sparking.
method  fault    // 1.
   fault(   f1001 ) = 'Condensation in the distributor cap'.
   fault(   f1002 ) = 'Faulty distributor arm'.
   fault(   f1003 ) = 'Worn distributor brushes'.
method  symptom  // 1.
   symptom( s1001 ) = 'The starter turns but the engine doesnt fire'.
   symptom( s1002 ) = 'The engine has difficulty starting'.
   symptom( s1003 ) = 'The engine cuts out shortly after starting'.
   symptom( s1004 ) = 'The engine cuts out at speed'.
method  effect   // 1.
   effect(  f1001 ) = s1001.
   effect(  f1002 ) = s1001.
   effect(  f1002 ) = s1004.
   effect(  f1003 ) = s1002.
   effect(  f1003 ) = s1003.
method  contrary /  2.
   contrary( s1002, s1001 ).
   contrary( s1003, s1001 ).
end distributor.
The fault Class
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% CLASS  : fault                                                  %
% COMMENT: How to search for and report faults                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

class fault .

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                           DECLARATIONS                          %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

category
   fault ,                  % A class in the fault diagnosis
   user .

public methods
   findall         /  0 .   % Find and report all possible faults

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                           DEFINITIONS                           %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% METHOD : findall/0                                              %
% COMMENT: Find and print all possible faults                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

findall :-
   dynamic( told_by_user / 2 ),
   forall (
           ( Where = self
           ; Where = descendant_class ),
           Where <- find( Fault )
          )
   do     (
           write( 'Location      : ' ), write( Where ), nl,
           write( 'Possible Fault: ' ), write( Fault ), nl, nl
          ).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% METHOD : find/1                                                 %
% COMMENT: Find a possible fault for some class                   %
%          Explicit use of 'self' to avoid any early bindings!    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

find( Fault ) :-
   public( fault // 1 ),
   Fault = self@fault( FaultNumber ),
   forall SymptomNumber = self@effect( FaultNumber )
   do     exhibited( SymptomNumber ).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% METHOD : exhibited/2                                            %
% COMMENT: Ask the user whether or not the symptom is             %
%          exhibited & remember                                   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

exhibited( SymptomNumber ) :-
   told_by_user( SymptomNumber, Reply ),
   !,
   Reply = yes.

exhibited( SymptomNumber ) :-
   cat( [self@symptom(SymptomNumber),'?'], Question, _ ),
   ( yesno( Question ) -> Reply = yes ; Reply = no ),
   asserta( told_by_user( SymptomNumber, Reply ) ),
   Reply = yes,
   forall ( self <- contrary( SymptomNumber, ContrarySymptom )
          ; self <- contrary( ContrarySymptom, SymptomNumber ) )
   do     asserta( told_by_user( ContrarySymptom, no ) ).

end fault.

The Output

?- faults <- findall .

Location       : distributor
Possible Fault : Condensation in distributor cap

Location       : distributor
Possible Fault : Faulty distributor arm
No more solutions