Generated Rules Inspected For Compound Negation

We noticed generated rules in our inspection results when using a compound negation rule. I don't think this is expected, and may be a result of an exception being thrown. Here is a simple test to reproduce:

(defrecord RuleTest [color state])

(defquery class-query
  "Return all results"
  []
  [?result <- ClaraResultWrapper])

(defrule joeMamaRule
  "joeMamaRule"
  [:not
   [:and
         [RuleTest (= "orange" color)]
         [RuleTest (= "liquid" state)]
         ]]
  =>
(print "****Rule Executed****\n"))

(defn -main
  []
   (clarainspector/explain-activations (-> (mk-session [joeMamaRule class-query])
      (insert (->RuleTest "orange" "liquid"))
      (fire-rules))))

Running this will produce the unexpected behavior, but also indicates an exception had occurred:

rule myrule.test/joeMamaRule__G__7701
  executed
    (clara.rules/insert! (clara.rules.engine/->NegationResult myrule.test/joeMamaRule__G__7701))
  with bindings
     {}
  because
Exception in thread "main" java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap, compiling:(/private/var/folders/4l/t6wwdv9177dbp7x8swwwk7vmkg8vlj/T/form-init2501212382920230134.clj:1:125)
	at clojure.lang.Compiler.load(Compiler.java:7391)
	at clojure.lang.Compiler.loadFile(Compiler.java:7317)
	at clojure.main$load_script.invokeStatic(main.clj:275)
	at clojure.main$init_opt.invokeStatic(main.clj:277)
	at clojure.main$init_opt.invoke(main.clj:277)
	at clojure.main$initialize.invokeStatic(main.clj:308)
	at clojure.main$null_opt.invokeStatic(main.clj:342)
	at clojure.main$null_opt.invoke(main.clj:339)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	at clojure.lang.RestFn.invoke(RestFn.java:421)
	at clojure.lang.Var.invoke(Var.java:383)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap
	at clojure.lang.RT.nthFrom(RT.java:947)
	at clojure.lang.RT.nth(RT.java:897)
	at clara.tools.inspect$explain_activation.invokeStatic(inspect.clj:197)
	at clara.tools.inspect$explain_activation.invoke(inspect.clj:193)
	at clara.tools.inspect$explain_activations.invokeStatic(inspect.clj:232)
	at clara.tools.inspect$explain_activations.doInvoke(inspect.clj:212)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at myrule.test$_main.invokeStatic(test.clj:73)
	at myrule.test$_main.invoke(test.clj:70)
	at clojure.lang.Var.invoke(Var.java:375)
	at user$eval5.invokeStatic(form-init2501212382920230134.clj:1)
	at user$eval5.invoke(form-init2501212382920230134.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:6927)
	at clojure.lang.Compiler.eval(Compiler.java:6917)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	... 14 more

This result only occurs when both/all parts of the AND logic evaluate to true, making the compound negation false (effectively not triggering the rule). If only one/some (or none) of the AND logic evaluates to true, the rule is triggered as expected, and the inspection results are as expected, meaning they only include our defined rule and no generated rules.

[mrrodriguez]

@wbautistaEXPEDIA

The exception looks related to a fix that is proposed with #346

Other than that, I'm not sure what unexpected behavior you are experiencing.
You are correct that negations of further "complex" conditions are extracted out to another rule. This is one way to deal with negated conjunctions. There is also #347 which has some relationship to rules of this form, but it isn't directly relevant to your issue here.

Can you elaborate on what behavior is unexpected for you other than the exception thrown when performing the introspection?

The unexpected behavior to which I'm referring is the inclusion of the generated rule in the results. I would expect the results to only contain rules I have provided. From my perspective, I am unfamiliar with <SOME_RULE_NAME>__G__<GENERATED_NUMBER>. I did not provide that as a rule, so I wouldn't expect it to have been triggered. Does that make sense? In the example I provided, I would expect no rule to have triggered, since the evaluation indeed results in my provided rule not being triggered.

[mrrodriguez]

@wbautistaEXPEDIA
Thanks for the explanation. I was making sure the rule functioned as expected, which it does when I ran the example locally.

I can see how the generated rule information showing up in the introspection traces could be confusing. That is a good point. I'm not sure what is the best approach to that one. It could be filtered out, however, then it may look like negation rules are not fired for no apparent reason. Perhaps it could just be made into something more readable when returned that explained what it was for better.

I can see why you'd expect perhaps no "firing rule" activity in the introspection results.

Yes, no question, the rule functions as expected. I verified this by changing the input to test each logical evaluation.

It could be filtered out, however, then it may look like negation rules are not fired for no apparent reason.

As a user, I don't know that this is a concern. In fact, it may lead to confusion (hence, the raising of this issue). Certainly, for testing clara-rules implementations, such as this compound negation implementation, this has value. However, the generated rules are implementation details. Maybe different audits could be provided to include/exclude generated rules. Or, as you suggested, maybe more information about the activations could be provided, such that generated rules are verbosely identified.

We may be alone in thinking this. Others may not be affected. We just wanted to ensure:

1. This is the expected behavior
2. This is not the result of that exception

If this was unexpected, we obviously wanted it brought to attention.

[WilliamParker]

• Regarding (2): I concur with @mrrodriguez that the exception is related to Fix exception in explain-activation #346. It is an unrelated issue.
• Regarding (1): IMO the behavior is expected under the current implementation but not desirable. The session inspection functionality just naively treats user-provided and generated negation rules in the same way. From a user's POV I think the least surprising behavior would be to behave exactly as if Clara hadn't generated any additional rules and to have all the relevant data returned under the original user-provided rule. It is actually something I've thought about implementing but hadn't gotten around to; for my part addressing the outstanding issues around complex negation functionality(Extracted complex negation rules do not respect binding groups #304, Support complex nested negations of arbitrary depth #343, Support negated conjunctions using new variable bindings #347) is higher on my todo list. It should also be noted that the complex negation extraction stuff is an implementation detail that could potentially change. Incidentally, I think you might run into similar sorts of confusing behavior in session inspection from Clara's DNF transformations for some boolean expressions.