I appreciate the kind words! You're right that the lines between forward- and backward-chaining systems are blurry, with some systems incorporating ideas from both. Perhaps more important than that is how easily we can express the logic for a given problem. While it's possible to write, say, a Sudoku solver in Clara, it really isn't the right tool for that sort of constraint-based logic. Conversely, some forward-chaining rules may not be as easily expressed in a system that emphasizes constraints. Some examples I put together to demonstrate Clara are at [1]; I hope these are fairly clear. I'm not so sure this type of arbitrary, changing business logic is as easy to modularize and express in other systems.
To be clear, I think core.logic is awesome, and am uncomfortable drawing any comparison between it and Clara. I also can imagine leveraging core.logic and its ideas in Clara itself as this evolves. As a starting point, however, Clara is targeting a different class of problem. If working with a problem that could benefit from rules, I'd suggest thinking of the simplest way that problem can be expressed, and choosing a technology that most closely aligns with that. I hope this makes sense! I wish I had some clear litmus test to contrast these systems, but I'm still learning myself. ;) [1] https://github.com/rbrush/clara-examples/tree/master/src/main/clojure/clara/examples On Tuesday, September 24, 2013 2:02:33 PM UTC-5, Dmitry Groshev wrote: > > I see your point. By the way, the documentation is outstanding, especially > for first release. Great work! > > On the other hand, I can't help but think that Rete algorithm looks like a > part of logic programming system. I understand that this is a corner case > (Prolog does a lot more than just scanning through facts/rules) and > therefore can be solved much more efficiently, but is there a way to blend > this approaches? I've also found [1] and this supports my suspicion that > the distinction is more of a historic/business kind rather than fundamental > one. > > Your argument on execution order problems is valid, especially for Prolog. > But minikanren is not so brittle in this sense. Moreover, "runtime" > assertion of facts in regard to core.logic already surfaced a few times in > this list [2], so effective addition of facts and rules can be very > beneficial for core.logic. On the other hand, if I understand correctly, > information on constraints (both real, integer and FD) can be useful for > rule-based systems to reduce search space of rules that can be affected by > new fact. So combined approach seems useful to me. > > [1]: > http://programmers.stackexchange.com/questions/114711/the-relation-between-business-rules-engines-and-constraint-programming-languages > [2]: http://osdir.com/ml/clojure/2013-03/msg00778.html > > On Tuesday, September 24, 2013 3:42:02 PM UTC+4, Ryan Brush wrote: >> >> Clara is a forward-chaining production system -- think Jess, Drools or >> CLIPS (but in pure Clojure, of course.). Core.logic offers constraint-based >> logic programming, more along the lines of Prolog and obviously with a >> strong relationship to Kanren. >> >> These approaches are complementary; which one to use really depends on >> the problem you want to solve. If you can describe a problem as a search >> space over a set of constraints, core.logic is almost certainly a better >> fit than Clara. >> >> In contrast, Clara targets the expression of complex and arbitrary >> domain-specific knowledge. Even a functional approach to programming can >> become unwieldy if business rules are frequently changing and have >> arbitrary relationships to other rules. Those functions would need to be >> deeply chained together, with frequent changes forcing them to be re-wired. >> Production systems allow the logic to be expressed independently, where >> authors need not worry about other rules, order of execution, or wiring >> them together. The engine then runs the rules against a set of input and >> ensures the working memory reaches a consistent state. >> >> I wrote about this in more depth here: >> https://github.com/rbrush/clara-rules/wiki/Introduction >> >> On Tuesday, September 24, 2013 5:41:01 AM UTC-5, Dmitry Groshev wrote: >>> >>> I'm curious how this relates to core.logic. If I understand correctly, >>> Clara can be compiled to core.logic and utilize it's search, doesn't it? >>> >>> On Tuesday, September 24, 2013 6:16:12 AM UTC+4, Ryan Brush wrote: >>>> >>>> This is the first release of Clara, forward-chaining rules in Clojure. >>>> >>>> Details on the github site: >>>> >>>> https://github.com/rbrush/clara-rules >>>> >>>> I've also posted the rationale for what I'm doing here: >>>> >>>> http://www.toomuchcode.org/2013/09/rules-as-control-structure.html >>>> >>>> The gist is that forward-chaining rules are a great tool for many >>>> problems and Clojure's strengths can address some weaknesses in existing >>>> production systems. Right now Clara supports most of the major features >>>> seen in production systems, embraces Clojure values like immutability, and >>>> is powerful enough for a number of use cases. It still needs to be >>>> profiled >>>> and subjected to more rigorous testing before I'd consider it production >>>> ready, but this release is for anyone interested in experimenting with it. >>>> >>> -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
