Shantanu, I appreciate it. I did look at Mimir, but had some different objectives, and therefore tradeoffs, and didn't see a straightforward way to reconcile them.
First, I wanted to use existing data models in the rules as is -- be it Clojure records, Java Beans, or other structures. Drools has a number of drawbacks, but has success in Java-land largely because it interoperates with existing models so well. A pure Clojure solution with strong interop could offer a number of advantages over existing engines. In fairness, I have yet to add first-class Java support, but the same structure that uses Clojure records right now will be extended to seamlessly use JavaBeans-style classes. Second, I have a broader goal of executing rules against arbitrarily large data sets in a distributed system, and there are semantic and structural tradeoffs to make that happen. For instance, the underlying working memory is a separate subsystem in Clara, and all join operations are hash-based and structured in such a way that they need not be performed in the same process. The clara-storm project is a very raw proof-of-concept of distributing rules across a cluster, but we should be able to layer it on top of other infrastructures as well, such as Hadoop (although that's another, involved conversation in itself.) At this point I'm more focused on getting the core system correct and useful on its own, doing enough to ensure this will be scalable in the future. There are a number of other distinctions that could probably be reconciled with Mimir's approach, such as the use of Jess- or Drools-like Accumulators to reason over collections of objects. To be honest I didn't look closely on how that could be done given some of the above differences. Thanks! -Ryan On Sunday, August 18, 2013 2:54:32 PM UTC-5, Shantanu Kumar wrote: > > Thanks for posting. I will certainly explore this. > > Did you look at Mimir? https://github.com/hraberg/mimir Could you outline > how is Clara's approach different from Mimir? > > Shantanu > > On Sunday, 18 August 2013 23:46:14 UTC+5:30, Ryan Brush wrote: >> >> Perhaps the best aspect of Clojure is how it can adopt the best ideas >> from other domains to concisely solve problems, as we've seen with >> core.logic, core.async and other libraries. I recently came across a >> problem domain that is easily expressed in forward-chaining rules, and >> found Clojure to be a powerful way to solve it. >> >> While working through this problem space I started to suspect there is a >> more general need for forward-chaining rules in Clojure to complement >> core.logic and other libraries. So as a side project I implemented a raw >> but working engine to do so. I'm posting here to share a draft of this >> engine, its major design goals, and to ask for input on how we should >> approach forward-chaining rules in Clojure in general. >> >> The rationale and some examples are on the github page for this >> engine<https://github.com/rbrush/clara-rules>, >> which I've tentatively named Clara. The state of the code isn't where it >> needs to be yet; I've been learning the intricacies of Rete and discovering >> better ways to solve problems along the way, and some of that is reflected >> in the code base. However, the major pieces of design and functionality are >> in place, so I'd like to get input on those. >> >> The idea is to draw a bit from Jess and Lisa, with the Java interop >> strength of Drools, but the advantages and idioms available in Clojure. The >> major goals are: >> >> - Focus on problem spaces naturally expressed as forward-chaining >> rules. Data-driven needs like eventing, data validation, or application >> of >> arbitrary business rules fit here. >> - Embrace immutability. The rule engine's working memory is a >> persistent Clojure data structure that can participate in transactions. >> All >> changes produce a new working memory that shares state with the previous. >> - Rule constraints and actions are simply Clojure s-expressions. >> - First-class Java interoperability and APIs. This should be an >> alternative to Jess or Drools from Java-land. >> - Usable either as a library to simplify Clojure code, or as a DSL to >> externalize business logic. >> - Working memory facts are typically (but not exclusively) Clojure >> records or Java objects following the Java Bean conventions. >> - Support the major advantages of existing rules systems, such as >> explainability of why a rule fired and automatic truth maintenance. >> - Collections of facts can be reasoned with using accumulators >> similar to Jess or Drools. These accumulators leverage the reducers API >> and >> are transparently parallelized. >> - The working memory is independent of the logic flow, and can be >> replaced with a distributed processing system. A prototype that uses >> Storm <https://github.com/rbrush/clara-storm> to apply rules to a >> stream of incoming events already exists. >> >> I'd love to hear thoughts on a couple questions: >> >> What else would you want from a forward-chaining rules engine in Clojure? >> What design changes would you make, given the above criteria and examples >> on github? >> >> All thoughts are appreciated! >> >> -Ryan >> >> https://github.com/rbrush/clara-rules >> https://github.com/rbrush/clara-examples >> https://github.com/rbrush/clara-storm >> >> -- -- 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.
