Clojurians Log v2
clara
So I was planning on having SideEffect being a defstructure that I insert that includes a function to call... Would I expect that to be a problem? I figured it can be inserted/retracted and then side effect doesn't happen (or does if rule still true at end).
Also I wanted to ask, what's the "cleanest" way to split up rules in one namespace if I want to reason about a couple of different things?
@joel380, > So I was planning on having SideEffect being a defstructure that I insert that includes a function to call... Would I expect that to be a problem? Assuming that you are not leveraging the “durability” feature, I wouldn’t expect this to be an issue.
for, > I figured it can be inserted/retracted and then side effect doesn’t happen (or does if rule still true at end). Clara guarantees the truthiness of the facts in the session once it reaches a steady state. The route that clara takes to reach this conclusion is not guaranteed, meaning that clara might interpret something as truthful and then reconsider it based upon changes in the session. Meaning that if the rule triggers side effects other than inserting facts into the session those side effects may occur, regardless of the end state of the session.
> Also I wanted to ask, what’s the “cleanest” way to split up rules in one namespace if I want to reason about a couple of different things? I actually try to breakup rules into their own namespaces by what they are trying to reason about
@joel380 @ethanc
on the side effect thing, Ethan explained well.
If you are saying you are modeling your “effects as data/facts” and don’t intend to perform the “function to call” until after the rules have fired and those (if any) effect facts are queried out of working memory to then perform the actual effects, then the idea makes sense to me.
This is sort of re-frame-like in modeling the effect as data and performing it separately (in this case, outside of the fire rules loop).
> I actually try to breakup rules into their own namespaces by what they are trying to reason about
+1 to breaking up rules.
Also, keep in mind mk-session can take a sequence of “rule sources”. This doesn’t have to be full namespaces. It can be individual productions - typically made via defrule & defquery DSL - or clj vars with :production-seq true in the meta.
I think :production-seq is for post-macro format? Is there an example? I know about listing the rules, was trying to avoid that. I totally agree that separate namespace would be ideal, but for the use case I'm looking at the entry point (dynamic loading) would be simpler as a consistent ns. I'm thinking a filter of the rules based on their name prefix... but then that means i need reverse filter for the rest. Awkward, but maybe for my case reasonable.
https://github.com/cerner/clara-rules/blob/ce65c5071a271905786449db1190687ee40e4624/src/test/clojure/clara/sample_ruleset_seq.clj Maybe if you follow from this can see example. I have to look around to find a better one. (Only on phone at the moment. )
The :production-seq option is for tagging a var that holds a list in a namespace that its rules should be considered part of the namespace when using the namespace (more precisely, the symbol of the namespace) as a rules source. You don’t need that (or any) metadata on a collection if you just pass the rules in to mk-session, and they don’t have to be literally referenced - you can use any Clojure code that evaluates to the collection. So (mk-session (arbitrary-fn-that-returns-collection-of-rule-data-structures)) would work. You could, say, have that function scan the vars in a namespace yourself and filter them on the name, their metadata, or other criteria you choose. To be honest I think it’s hard to say much about the ideal way to organize rules without knowing more about the use-case in question.
One other thought is that it is entirely possible to have a single session with highly partitioned “regions” based on the rules DAG. For example, a “cluster” of rules that produce a single output and that have no other interactions with different “clusters” of rules. This requires some discipline in whatever conventions you establish of course, but it is possible to have separation of concerns within the rules of a single session.
Thanks for the points on :production-seq @wparker I never got back to that one. I’ll note that I’m thinking it will not be a good idea to do (mk-session (arbitrary-fn-that-returns-collection-of-rule-data-structures)) in CLJS by the way, but I think we are only discussing CLJ here. See https://github.com/cerner/clara-rules/issues/388#issuecomment-489747471 for more on my endless struggle w/our current CLJS impl if that is of interest to you. 😱
Yeah, :production-seq is clj-only. I am indeed interested in the cljs stuff you logged 🙂 , just haven’t had time to review it yet unfortunately