On Sunday, August 18, 2013 1:41:56 PM UTC-7, Ryan Brush wrote: > > 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. >
I have been working on a similar approach - only using datomic as the "working memory". At one point I briefly considered putting the rete nodes into datomic but quickly realized that wasn't a good idea. The datomic datalog engine is very impressive. I wondered if using that in combination with datomic's tx-report-queue API might be worth looking into - instead of running full queries there could be incremental or "persistent queries" that yield tuples matching the datalog expressions in a lazy fashion. > > 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. > Let me know if you need help. It looks like you are farther along than I am. I agree that clojure is a great medium for a rules engine... I was looking at trying to leverage a lot of the existing match/logic/unification libraries as much as possible but it looks like your engine doesn't rely on them except for core.reducers. You asked about what features I would like to see - does Clara work in the browser/cljs? I haven't tried it yet - do you know any reason why it wouldn't? Alan > 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.
