Fork me on GitHub

Thanks @mikerod ! I am creating an empty session at this point. That seems to resolve these errors.


Hmm. Interesting. Well feel free to ask if you have more questions.


If the only thing that changes in the LHS of a rule is an accumulator value, is it correct that the rule won't fire if the collection of facts matching the accumulator condition change?


I would think that if an accumulator saw a new value, and the previously accumulated objects changed that there would be work that the rhs would have to do. Though I might be misunderstanding your question


That's how I want it to behave, but I have a distant recollection that it doesn't actually work that way. Been awhile since I've played with clara.


@dave.dixon, are you thinking of the retract-fn’s behavior?


Could be. Possible I'm just writing my accumulation clause wrong or something, because sometimes it does seem to behave as you described.


@dave.dixon in current version of Clara (and several before) the rule will not continue to propagate if the accumulated value hasn’t changed according to = See lines like


So specifically if the accumulators result from the :convert-return-fn is = to what it was in the previous round of accumulating fact matches, propagation stops - which would imply no RHS action being triggered/activated


The tests near what Jody pointed too could be enlightening on some more semantics though. I agree


There are quite detailed github issues out there that also discuss these semantics when we added the related changes.


@mikerod Thanks. Not exactly sure what I was thinking of. My actual problem was that I was hacking at something trying to make it update in place rather than letting truth maintenance do the lifting. Need to get back to "thinking TMS" 😉


Yes. No mutate in place. That’ll indeed cause issues.