Fork me on GitHub
#clara
<
2017-09-07
>
dadair04:09:25

Is there any reason why a LHS such as [A (= ?x x)] [B (= ?y y)] where x and y definitely exist (non-nil), would not fire with the order [A ..] [B ..] but would fire with [B ..] [A ..]?

mikerod13:09:41

@dadair I don’t see how it should be different. Do you have a more complete rule example?

mikerod13:09:53

Just to be sure you don’t have any extra constructs in play?

wparker14:09:48

@dadair @U0LK1552A I wouldn’t expect that kind of ordering to make a difference for non-accumulator rule conditions normally. If you are using manual retractions in rule RHS’s (right-hand-sides) you might be able to get yourself into some odd situations with undefined behavior that could be impacted. A more concrete reproducing example would be helpful to see if there’s a bug. For accumulators, it isn’t the easiest edge case to hit, but https://github.com/cerner/clara-rules/issues/218 is outstanding.

wparker14:09:53

Also, regarding your example

`[A (= ?x x)] [B (= ?y y)]
` I wouldn’t actually expect whether x or y is nil to impact whether the rule fires at least based on those conditions alone

wparker14:09:52

those aren’t result bindings, having a field value of a fact be nil (but the fact itself being nil) is a reasonable possibility and Clara will handle that

mikerod15:09:11

Yep, that’s the reason was asking for more details to be sure there aren’t things like accumulators in play. Things get more complicated then.

dadair16:09:44

There seemed to be an issue with using a pre-cached rule session. I was looping through some known mk-session configurations and swapping them into an atom so I could avoid the first performance hit. Then later I'd pull the specific session out of the atom and would insert some facts and fire rules. For some reason this was causing really weird rule activation problems

dadair16:09:55

So for now I've inlined the mk-session and am taking the performance hit until I can figure out what was going on

mmer14:09:22

Could someone please explain the rhs please - I have put a print and an insert! following on from each other on the rhs and the print always happens even if the rule fails?

mikerod14:09:26

@mmer The most typical way to structure rules is in a way that they logically express their constraints, but do not necessarily have a guaranteed order the RHS may fire in. insert! inserts facts that are subject to the “truth maintenance system” (aka the TMS) of the rules engine. If a rule fires at some point due to a, potentially transient, match of some facts, but later some of those facts are retracted, the engine will automatically retract the facts that relied on that match being present.

mikerod14:09:44

When you do a side-effect like a print, there is no way to “retract” the side effect

mikerod14:09:39

There are ways to structure rules that would prevent them from being able to ever fire their RHS “early”. This can be done with setting up the rule to not be able to fire due to some “blocking” or “guarding” criteria in the LHS that you know will not change it’s truthiness later. Also, you can sometimes do some tricks with :salience. However, in many cases, the best idea may be to just avoid the side-effects in the RHS and perhaps do them outside of the rules based on the facts that are found via queries after performing a fire-rules cycle.

mikerod14:09:22

There is some documentation on the TMS @ http://www.clara-rules.org/docs/truthmaint/

mmer14:09:54

That helps. I thought I was going mad!

mikerod14:09:48

@mmer yeah, it can be a tricky detail

mmer14:09:23

The docs say you can nest the boolean operators [:not, :or] etc. I have tried to do something like [:not [:or [] []] without much success. Is this just plain wrong on my part?

mikerod14:09:44

@mmer things can get a little tricky with that

mikerod14:09:13

So it is good to note that :or is sort of “syntactic sugar” in rules

mikerod14:09:36

It can almost be thought of as just splitting the rule into 2 (or more depending on logic in use) rules

mikerod14:09:31

e.g.

(r/defrule with-or
  [A (= ?id id)]
  [:or
   [B (= ?id id)]
   [C (= ?id id)]]
  =>
  (r/insert! (->D)))
Is similar to just writing
(r/defrule side-one
  [A (= ?id id)]
  [B (= ?id id)]
  =>
  (r/insert! (->D)))

(r/defrule side-two
  [A (= ?id id)]
  [C (= ?id id)]
  =>
  (r/insert! (->D)))

mikerod14:09:42

The point in that case is that there isn’t something like “short-circuiting”

mikerod15:09:02

and the :or has certain variable visibility issues due to how that works out

mikerod15:09:25

When it comes to :not + :or and/or nested :and, it may also be good to note that the engine will convert to DNF (disjunctive normal form)

mikerod15:09:57

There may be some variable visibility issues in that transition in certain complex cases

mikerod15:09:13

@mmer but if you have an example that demonstrates an issue you are seeing, it’d be probably clearer to just look at that one and explain what is going on

mmer15:09:36

I have eventually just split the rules in two so I do not need the not

mikerod15:09:59

sometimes it is clearer to split things up from an comprehension perspective anyways

mikerod15:09:47

Probably the most details on this subject can be found in the lengthy old issue comments @ https://github.com/cerner/clara-rules/issues/149

mikerod15:09:56

as far as some of the transformations that happen

mikerod15:09:33

Only if you were interesting in details though. 😛 Probably not super easy to read through.

mmer16:09:42

To be more precise - when I load up the rules/queries into the session I get :

mmer16:09:46

ExceptionInfo Value does not match schema: {:constraints [(not ("s-expression" ?composition)) (not ("s-expression" a-clojure.lang.Symbol))]} schema.core/validator/fn--1296 (core.clj:155)

wparker16:09:15

@mmer that looks like a syntax error in a rule/query

mmer16:09:05

What sort of thing am I looking for in my rule etc?

mikerod16:09:20

It’s hard to decipher without the actual rule DSL that was written (probably could be improved in Clara to try to capture that better) There is probably some missing [ ] if not just having syntax out of order