Clojurians Log v2

@jvtrigueros that is correct, the parameter of the query should be :?last-name, and would work similar to a filter on the ?last-name binding in the lhs of the query. Where did you find that example, it should probably be updated?

nvm, i found it: https://github.com/cerner/clara-rules/blob/master/src/main/clojure/clara/rules.cljc#L51

Sweet! Thanks 🙂

I'm curious about a number of Clara's language restrictions. For example, not being able to use :and inside not, not being able to use :and on the rhs of an accumulator.

Are these technical limitations of the underlying matching engine, or front-end limitations?

ya that one is a tangled web of very complicated issues...let me see if i can find the logged issues on them because there is a lot of good conversation on them

https://github.com/cerner/clara-rules/issues/373 this is one of them

has a lot of references to other issues

Yep @zylox has a good point on the issues around the complexities.

In general negated conjunctions and rete have complexities due to the structure of the network

Most of the times if things get weird in a rule doing this stuff I think you can typically just break the logic up across more rules to keep the structures simpler

How cheap are intermediate facts? I mean, clojure records themselves are cheap, but is memory used by facts interesting? They are alpha-pruned, I assume.

The idea of a NegatedCondition, for example, is that going to be more memory. (Also, I’m not sure how that could work, because it would need to join on a variable number of bindings.)

@eraserhd they aren’t much overhead beyond the fact object itself

You can make a rule that does the conjunction and inserts a fact if it is true. Then a rule with a negation on that fact. Clara actually sometimes automatically does something similar to that.

Intermediate facts in memory are about the same as just making a new record of whatever is what I meant. Cpu timewise just depends on what it interacts with. The actual working memory insert and retract operations are pretty fast (optimized it quite a bit)

Not sure if that addresses all your questions there

I think so.

When writing rules I typically go pretty heavy on intermediate facts

With preference on making simple rules that models smaller concepts at a time and then compose them together for main outcome models for query. If that makes any sense.

same here

what if i have three rules that act on type A and they all output type B while “mutating” some state in the fact. will the final fact be type B with all the “mutations”?

any time you mutate a fact in the rules network youve opened pandoras box

if you mean creating new intermediate facts, you will have 3 B facts at the end

but the foundation of the rules network is immutability.

you could have a rule that pulls in those 3 B facts (probably with an accumulator), and inserts a FinalB fact that has their combined state. ive seen this pattern used to solve a number of things