Sure! I'm definitely a fan of Jess, and I hope that Clara will feel pretty familiar to users of it. There is a lot of commonality, as both are Lisp-based forward-chaining rules with similar semantics. There are some syntactic differences -- I didn't pull over some of Jess's shorthand syntax, and I preferred to reuse Clojure constructs wherever they seemed to fit, such as using Clojure records and other built-in data structures as facts.
The biggest difference is that Clara allows users to plug into the entire Clojure ecosystem, where facts can be arbitrary data structures, rules can use arbitrary Clojure code, the working memory itself is an immutable, persistent data structure, and so on. Like Jess, Clara offers good Java interoperability, but can also be used as a simple library in a bigger Clojure code base. Being only a few months old, Clara hasn't reached the maturity of Jess, but by plugging into the full Clojure ecosystem I think it has a stronger foundation. This is allowing it to be adapted for a wider variety of use cases. For instance, the work I'm doing now will allow users to inspect all rules and the Rete network itself as a data structure, opening the door for rule generation or visualization tools of the logic itself. (I expect to push the foundation of this to Github in the next week or two.) I hope this answers your question! It's tempting to keep listing the things I plan on doing with Clara, but it all boils down to the ability to leverage Clojure and ClojureScript themselves. On Thursday, December 19, 2013 4:26:39 PM UTC-6, Sven Richter wrote: > Hi Ryan, > > > > this is a bit off topic, but as a Jess user I am curious if you know the Jess > engine and could leave a few words about how Clara compares to Jess, if it > does at all? > > > > Best Regards, > > Sven > > > > Am Freitag, 29. November 2013 15:18:14 UTC+1 schrieb Ryan Brush: > > > A release is coming soon, but I wanted to share some notes on bringing > > forward-chaining rules in Clara to ClojureScript -- and confess some sins > > of questionable use of ClojureScript's internals. Overall this went really > > smoothly, and links to the project an an example use are below. > > > > > > > > > > > > Amazing (at least to a ClojureScript newbie like me) is the fact that I > > encountered zero unexpected behavior differences between Clojure and > > ClojureScript. All of Clara's logic for shredding rule definitions and > > assembling them into an optimized Rete network moved unchanged. > > > > > > > > > > > > The same goes for Chas Emerick's clojurescript.test. All of my tests > > transitioned unchanged (excluding the Java interop tests, of course.) This > > alone made adoption of ClojureScript much easier. > > > > > > > > > > > > Almost as amazingly is how an example rule set using Clara and Dommy (and > > all of the ClojureScript dependencies) gzips to 49 kilobytes when compiled > > in advanced mode. This is with zero optimization effort on my end. > > Additional rules or other logic increase this only minimally. Such a low > > cost makes forward-chaining rules in the browser a real option for a lot of > > problems. > > > > > > > > > > > > For this project I actually used lein-cljsbuild's crossovers rather than > > cljx. With some restructuring of the code, there were clear, logical > > boundaries between logic for each platform and logic that could be shared. > > cljx looks great and I may use it in the future, but it seemed cleaner to > > skip a preprocessing step for a project that doesn't really need it. (The > > one exception to this is the unit tests, which are largely copied between > > cli and cljs…but that bothers me less for unit tests.) I see that > > crossovers may be removed in the 2.0 stream of lein-cljsbuild, but I do > > like having such a simple option. > > > > > > > > > > > > Now for confessing some sins: as a convenience for the user, rule engines > > often have implicit knowledge about the slots in each fact. Since Clara > > supports Clojure(Script) Records as facts, this means it needs to know what > > fields exist in a given record type at compile time. I just used reflection > > in Clojure for this, but the only solution I could find in ClojureScript > > was to tap into the internals of the analyzer, locating the record > > definition in the environment, and grabbing the fields from it. Obviously > > this is fragile. I'm okay with updating Clara at any time when and if the > > ClojureScript structure changes…although in the long run I'm wondering if > > we could consider making some of ClojureScript's environment formalized for > > use in such metaprogramming. > > > > > > > > > > > > I could remove this functionality outright, but that conflicts with another > > goal: I really want to make Clara an appealing alternative for someone > > looking at other engines Drools…and I think this functionality is > > significant for that. > > > > > > > > > > > > Overall, my first significant use of ClojureScript couldn't have gone much > > better. Many thanks to everyone working on it! > > > > > > > > > > > > -Ryan > > > > > > > > > > > > Clara source code: > > > > > > https://github.com/rbrush/clara-rules > > > > > > > > > > > > ClojureScript example: > > > > > > https://github.com/rbrush/clara-examples/blob/master/src/main/clojurescript/clara/examples/shopping.cljs -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
