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.
