Fork me on GitHub
#clara
<
2018-10-26
>
ethanc15:10:50

@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?

jvtrigueros16:10:05

Sweet! Thanks 🙂

eraserhd17:10:15

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.

eraserhd17:10:03

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

zylox17:10:34

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

zylox18:10:45

has a lot of references to other issues

mikerod18:10:40

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

mikerod18:10:37

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

mikerod18:10:54

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

eraserhd18:10:00

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.

eraserhd18:10:44

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.)

mikerod19:10:20

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

mikerod19:10:13

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.

mikerod19:10:29

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)

mikerod19:10:44

Not sure if that addresses all your questions there

eraserhd19:10:57

I think so.

mikerod19:10:31

When writing rules I typically go pretty heavy on intermediate facts

mikerod19:10:09

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.

zylox19:10:38

same here

ben.borders20:10:44

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”?

zylox20:10:40

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

zylox20:10:00

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

zylox20:10:24

but the foundation of the rules network is immutability.

zylox20:10:33

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