7:23:46 Hours of High Quality Videos
Prolog = Programmation en Logique (Programming in Logic). Prolog is a declarative programming language unlike most common.
Full lifetime Access
178 9.99
Simply Easy Learning
Created by Arnab Chakraborty, Last Updated 08-Aug-2019, Language:English
Arnab Chakraborty
Corporate Trainer
Prof. Arnab Chakraborty is a Calcutta University alumnus with B.Sc. in Physics Hons with Gold medalist, B. Tech and M. Tech in Computer Science and Engineering has twenty-three+ years of academic teaching experience in different universities, colleges and eleven+ years of corporate training experiences for 150+ companies and trained 50,000+ professionals. He has also completed MBA from Vidyasagar University with dual specialization in Human Resource Management and Marketing Management. He is NLP and PMP trained, Global DMAIC Six Sigma Master Black Belt certified by IQF, USA. He is certified by ISA, USA on 'Control and Automation System'. He is also Global ITIL V3 Foundation certified as awarded by APMG, UK. Qualified for Accredited Management Teacher by AIMA. He is also empaneled trainer for HP, Accenture, IBM etc.
More Courses from Arnab Chakraborty
Active11 months ago
I read somewhere that you can think of modules as objects in Prolog. I am trying to get my head around this, and if it a good way to code.
If I have two files, one defining a class dog and then another one that uses this class to make two dog objects.
second file
This makes a dog object Dog which is a basset hound and makes it bark 5 times,I then make another dog object Dog2 which is a bloodhound and make this also bark. I understand that in oop you have objects that have behaviours and state. So I now have two objects with different behaviours based on their own states but at the moment I am storing the state of the objects in the Dog variables where they can be seen by the code in the main program. Is there a way to hide the state of the objects i.e to have private variables? For example I might want to have a way of storing the state has_barked for each dog object, which would be true if it has barked earlier in the program and false otherwise, then change the behaviour of
bark/1
based on this.Also how would you handle inheritance and overriding methods etc? Any pointer to readings welcomed. Thank you.
Transfinite Numbers7,70333 gold badges2525 silver badges6969 bronze badges
user27815user27815
7 Answers
Just an example of one of the possible reimplementations of your sample code in Logtalk. It uses prototypes for simplicity but it still illustrates some key concepts including inheritance, default predicate definitions, static and dynamic objects, and parametric objects.
Some sample queries:
Some notes.
Paulo MouraPaulo Moura::/2
is the message sending control construct. The goal {Object}::Message
simply proves Object
using the plain Prolog database and then sends the message Message
to the result. The goal [Object::Message]
delegates a message to an object while keeping the original sender.13.8k22 gold badges1414 silver badges2626 bronze badges
Prolog modules can be trivially interpreted as objects (specifically, as prototypes). Prolog modules can be dynamically created, have a name that can be regarded as their identity (as it must be unique in a running session as the module namespace is flat), and can have dynamic state (using dynamic predicates local to the module). In most systems, however, they provide weak encapsulation in the sense that you can usually call any module predicate using explicit qualification (that said, at least one system, ECLiPSe, allows you to lock a module to prevent breaking encapsulation this way). There's also no support for separating interface from implementation or having multiple implementations of the same interface (you can somehow hack it, depending on the Prolog module system, but it's not pretty).
Logtalk, as mentioned in other answers, is a highly portable object-oriented extension to Prolog supporting most systems, including SWI-Prolog. Logtalk objects subsume Prolog modules, both from a conceptual and a practical point-of-view. The Logtalk compiler supports a common core of module features. You can use it e.g. to write module code in Prolog implementations without a module system. Logtalk can compile modules as objects and supports bi-directional calls between objects and modules.
Note that objects in Logic Programming are best seen as a code encapsulation and code reuse mechanism. Just like modules. OO concepts can be (and have been) successfully applied in other programming paradigms, including functional and logic. But that doesn't mean necessarily bringing along imperative/procedural concepts. As an example, the relations between an instance and its class or between a prototype as its parent can be interpreted as specifying a pattern of code reuse instead of being seen from a dynamic/state point-of-view (in fact, in OOP languages derived from imperative/procedural languages, an instance is little more than a glorified dynamic data structure whose specification is distributed between its class and its class superclasses).
Considering your sample code, you can recode it easily in Logtalk close to your formulation but also in other ways, the most interesting of them making use of no dynamic features. Storing state (as in dynamic state) is sometimes necessary and may even be the best solution for particular problems (Prolog have dynamic predicates for a reason!) but should be used with care and only when truly necessary. Using Logtalk doesn't change (or intends to change) that.
I suggest you look into the extensive Logtalk documentation and its numerous programming examples. There you will find how to e.g. cleanly separate interface from implementation, how to use composition, inheritance, specialize or override inherited predicates, etc.
Paulo MouraPaulo Moura13.8k22 gold badges1414 silver badges2626 bronze badges
Logtalk is effectively the prominent object oriented Prolog available today. Paulo made it available as a pack, so installing should be very easy.
Modules are not really appropriate for object orientation. They are more similar to namespaces, but without nesting. Also, the ISO standard it's a bit controversy.
SWI-Prolog v7 introduced dicts, an extension that at least handles an historical problem of the language, and make available 'fields' by name, and a syntax for 'methods'. But still, no inheritance...
edit
I've added here a small example of object orientation in SWI-Prolog. It's an evolution of my test application about creating genealogy trees.
Comparing the genealogy.pl sources, you can appreciate how the latest version uses the module specifier, instead of the directive :- multifile, and then can work with multiple trees.
You can see, the calling module is passed down the graph construction code, and have optional or mandatory predicates, that gets called by module qualification:
optional predicates must be called like
Note that predicates are not exported by the applicative modules. Exporting them, AFAIK, breaks the object orientation.
Another, maybe more trivial, example of of object orientation, it's the module pqGraphviz_emu, where I crafted a simple minded replacement of system level objects.
I explain: pqGraphviz it's a tiny layer - written in Qt - over Graphviz library. Graphviz - albeit in C - has an object oriented interface. Indeed, the API allows to create relevant objects (graphs, nodes, links) and then assign attributes to them. My layer attempts to keep the API most similar to the original. For instance, Graphviz creates a node with
then I wrote with the C++ interface
We exchange pointers, and I have setup the Qt metatype facility to handle the typing... but since the interface is rather low level, I usually have a tiny middle layer that exposes a more applicative view, and it's this middle level interface that gets called from genealogy.pl:
In this snippet, you can see an example of the SWI-Prolog v7 dicts:
The memory allocation schema is handled in allocator.pl.
CapelliCCapelliC52.9k44 gold badges3434 silver badges6666 bronze badges
the PCE system in SWI-Prolog is also an option for OOP in Prolog. It's usually associated with xpce, the GUI system, but it's actually a general purpose class based OO system.
AnniepooAnniepoo
Have a look at logtalk. It is kind of an object-oriented extension to Prolog.
schrobeschrobe39511 gold badge44 silver badges1919 bronze badges
Nowadays, SWI prolog has dicts which interact with the modules in a nice way. See The SWI prolog manual page on dicts, especially section 5.4.1.1: User defined functions on dicts.
This allows you to define things that look exactly like methods, up to returning values (unusual but very useful in Prolog).
Unlike discussed in some of the other answers, I personally find the logic programming and OOP paradigms to be orthogonal to each other: it definitely doesn't hurt to be able to structure your logic code using the OOP modularity...
tjltjltjltjl
Parameterized modules, like in Logtalk, are a little bit more than object oriented programming. I have reimplemented parameterized modules for another Prolog system here via a simple user module 'param'. This route to parameterized modules is via the ISO module standard.
In the barking dog example, even not object oriented programming is needed, could be done as well with ISO module standard straight forward directly. But lets show how it could be done by adopting the directive idea from Logtalk and doing it via the new module 'param':
File 1: dog.p
File 2: bassethound.p
File 3: bloodhound.p
Since the used Prolog system had an auto loader, we even didn'thave to do much of Prolog text loading. All that was needed was a pathto the sources. A porting to SWI-Prolog is pending, need to figure out variable name access and the blocking implication rewriting trick.
Transfinite NumbersTransfinite Numbers7,70333 gold badges2525 silver badges6969 bronze badges