To be clear, we can dynamically create and abolish at runtime objects, protocols, and categories and use dynamic object predicates. But that’s rarely the best approach. As in Prolog, we always strive for the most declarative solution.
So, when you solve problems with Logtalk - how do you go about it – what is the analysis / design method at work …
Does it correspond to typically OO analysis methods or does it require adopting a different thinking paradigm as well.
Dan
There are two starting points: the relational model and the object model. From a relational perspective, all the good advice from more traditional Prolog programming applies, specially about finding the best representations. The object model allows a much richer set of design patterns when compared with what’s sensible with Prolog modules (notably, without half-broken hacks). As you mentioned earlier, the object model brings structure based on declarative OOP concepts. The trap to avoid is start thinking in terms of imperative OOP with dynamic objects and mutable state taking central stage. Being aware of that, from a sufficiently abstract level, traditional OO design methods are useful and can be applied.
The two models, relational and object, can coexist nicely, specially in those cases where the relational model takes care of knowledge representation and the object model takes care of organizing the predicates that reason about the represented knowledge. One thing to keep in mind is that, just because you’re using Logtalk objects (same goes with Prolog modules) doesn’t mean that everything must an object (or a module). Keeping e.g. some data in plain Prolog, in RDF format, or even in an external database is sometimes the sensible choice. I.e. always be pragmatic. Related, note that most native Prolog resources (notably, libraries) can be used as-is from Logtalk.
When you get closer to the language level, there are some Logtalk features that enable creative solutions that are outside the radar of traditional Prolog programming. For example, parametric objects and event-driven programming enable clean, declarative solutions for a surprising number of problems. Libraries, such as the optionals and expecteds implementations, can also enable interesting solutions to tricky problems.
There’s an implicit learning learning curve here but the benefits are clear: a rich set of tools, patterns, abstractions, features, developed from the ground up from language and software engineering perspectives, that adds to what’s already available from the chosen Prolog compiler.
1 Like
Declarative handling of state as performed via predicates, grammar rules (both DCGs and EDCGs), or parametric objects (and, related, as handled by optionals and expecteds libraries and similar) is well understood. But my cautionary advice in my previous message is about mutable state (either using dynamic predicates or dynamic entities), which should always be avoided and, if not possible, minimized in Logtalk/Prolog applications. This is also common advice as mutable state breaks declarative semantics. What’s not (yet) widespread is the very idea of declarative object-oriented programming. Fighting and breaking the common and immediate association of objects with imperative semantics is key to move logic programming past the limitations of module systems.
Logtalk synchronized/1 directive is there for the same reasons that Logtalk and Prolog support dynamic predicates. Mutable state is sometimes required (by the application domain itself) and, in the context of multi-threaded applications, synchronization becomes necessary. Nothing really new here as the directive is an abstraction over mutex support as found in most multi-threaded Prolog systems.
Just to chime in about understanding models of state:
MIT open-courseware class on advanced data structures. (videos)
Check out the first lecture/session on Persistent Data Structures
I found it to be very beneficial.
Not most but around half of them. Not surprising considering that most of the patterns come from the Gof4 book, which is implicitly about imperative OOP and thus heavy on mutable state. For a few of them, alternatives are discussed and/or exemplified showing how to implement them using declarative state (via parametric objects) instead of mutable state (e.g. the builder creational pattern). The same declarative solution can be applied to other patterns. But these are just examples. The deciding factor on how best to implement an abstract design pattern is, as always, the application being built. The practical guidelines and consequent advice here is: does whatever used representation of state need to survive backtracking? If true, can those instances of mutable state be nicely encapsulated and thus isolated from the rest of the application? If false, predicates or grammar rules or parametric objects can be used to pass or thread the declarative and transient state using logical variables.
Most industry resources on OOP are about imperative/procedural OOP. The fundamental characteristic of imperative/procedural programming is mutable state and symbolized by the assignment operator. That doesn’t mean that alternatives don’t exist (e.g. CLOS is older than several today mainstream OOP languages) or that there’s necessarily a different language being used in industry and academia. It’s even worse actually. Easy to find books teaching OOP not only assuming imperative OOP but that OOP languages mean class-based languages. Most resources only focus on what’s mainstream. Easy to find discussions online where the only two programming paradigm contenders are functional and (imperative) OOP with zero mentions of logic programming as a third alternative. Recently, I read a blog post on how to do logic programming in Python with zero references to Prolog and Datalog. Sigh.
1 Like
Given the static approach to modeling objects, and object hierarchies, i am curious, what is the performance cost, if any. Is there some kind of subtype inference …
See https://logtalk.org/manuals/userman/performance.html Let me know if there are any question on performance that are not answered in that section.
For the more casual or impatient reader: McCabe’s thesis, “Logic and objects : language, application and implementation”, is open access: https://spiral.imperial.ac.uk/handle/10044/1/47568
1 Like
Thanks. It’s nice, but the reply was to me, I think it would have been more beneficial to Dan who ordered the book.
Thanks Eric.
It wasnt too expensive. Around 10 usd including shipping. Will save me the cost in printing and binding the book …
Dan