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.
