Clara vs Core.logic, comparison, possible interoperation, examples..

369 views
Skip to first unread message

Martin Baldan

unread,
Mar 22, 2017, 8:23:13 PM3/22/17
to Clara
Hello!

First, let me apologize for any beginner errors and misconceptions. I'm new to pretty much everything mentioned, including Clojure, rule engines and logic/relational programming. Also, I see this topic was discussed to some extent back in 2013 when Clara 0.1.0 was announced, but I figured it deserved revisiting, and also its own thread.

To make the question more concrete, my use case is a little chatbot I'm trying to make, which I think is a nice way to put several cool programming concepts together, starting small and simple and refactoring as needed. I forked it from Gigasquid's speech-acts-classifier. For the moment I just did trivial changes like renaming a few things from the original, but the grandiose plan is to parse user input with several strategies, including a controlled language encoded in an instaparse grammar, and then translate user input to "facts" in some logical formalism, to be stored persistently in some kind of database. For this purpose, particularly the "fact database" core.logic seems like a nice fit, as can be seen for instance, in the "features" section.

But then I'd like those "facts" to fire actions, like drawing conclusions and coming up with replies, based on general rules, and this sounds more like what Clara does. So I'm a bit at a loss on whether I should pick Core.logic, Clara or a combination of both. The problem I see with combining both is that the Clara "facts" which trigger its rules must come (I think, please correct me otherwise) in the form of Clojure maps or records, while the core.logic "facts" (in the features example, for instance) are relations stored in pldb.

So, I'm wondering if there's a standard way to bridge this gap. More generally, does it make sense to combine Clara and Core.logic through the pldb fact database, or in some other way, or not at all?

Thanks in advance!

Ryan Brush

unread,
Mar 25, 2017, 8:48:17 PM3/25/17
to Clara
Interesting question. I think that answer from 2013 you linked to still applies, where core.logic is a great fit for problems that can be described as constraints, and Clara works well for applying expert knowledge to your program's data model. That said, for many problems you can probably "fake" the behavior of one system in the other (even if it's not a perfect fit).

I haven't thought deeply how you'd combine the two. Clara is pretty extensible in that it can accept just about any Clojure structure, so you could conceivably pull in the same tuples used in core.logic and use a customized fact-type function to identify a type for Clara. However, I'm not sure this approach is really worth the complexity it introduces when compared to using the system that best fits most of your problem, even if it's not the best fit for all of the problem. By that I mean, if core.logic is a great fit for 90% of your use case, I'd probably just use it exclusively and work through the remaining 10% in core.logic, even if it's not ideal. And I think vice versa is true for Clara: if it works well for the bulk of your use case, you can fake core.logic-like behavior for the 10% where it doesn't.

Of course, I'd have to have a deep understanding of the problem you're working on to suggest the best approach for your specific case. But hopefully the above could help the thought process for evaluating this.
Reply all
Reply to author
Forward
0 new messages